linux-toradex.git/drivers/firmware, branch v6.8-rc7

Merge tag 'efi-fixes-for-v6.8-2' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi

2024-03-01T19:40:29+00:00

Pull EFI fixes from Ard Biesheuvel:
 "Only the EFI variable name size change is significant, and will be
  backported once it lands. The others are cleanup.

   - Fix phys_addr_t size confusion in 32-bit capsule loader

   - Reduce maximum EFI variable name size to 512 to work around buggy
     firmware

   - Drop some redundant code from efivarfs while at it"

* tag 'efi-fixes-for-v6.8-2' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi:
  efivarfs: Drop 'duplicates' bool parameter on efivar_init()
  efivarfs: Drop redundant cleanup on fill_super() failure
  efivarfs: Request at most 512 bytes for variable names
  efi/capsule-loader: fix incorrect allocation size

Merge tag 'riscv-firmware-fixes-for-v6.8-rc6' of https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux into arm/fixes

2024-02-23T12:53:44+00:00

Microchip firmware driver fixes for v6.8-rc6

A single fix for me incorrectly using sizeof().

Signed-off-by: Conor Dooley 

* tag 'riscv-firmware-fixes-for-v6.8-rc6' of https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux:
  firmware: microchip: fix wrong sizeof argument

Link: https://lore.kernel.org/r/20240221-recognize-dust-4bb575f4e67b@spud
Signed-off-by: Arnd Bergmann

efi/capsule-loader: fix incorrect allocation size

2024-02-13T15:30:07+00:00

gcc-14 notices that the allocation with sizeof(void) on 32-bit architectures
is not enough for a 64-bit phys_addr_t:

drivers/firmware/efi/capsule-loader.c: In function 'efi_capsule_open':
drivers/firmware/efi/capsule-loader.c:295:24: error: allocation of insufficient size '4' for type 'phys_addr_t' {aka 'long long unsigned int'} with size '8' [-Werror=alloc-size]
  295 |         cap_info->phys = kzalloc(sizeof(void *), GFP_KERNEL);
      |                        ^

Use the correct type instead here.

Fixes: f24c4d478013 ("efi/capsule-loader: Reinstate virtual capsule mapping")
Signed-off-by: Arnd Bergmann 
Signed-off-by: Ard Biesheuvel

Merge tag 'efi-fixes-for-v6.8-1' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi

2024-02-09T18:40:50+00:00

Pull EFI fixes from Ard Biesheuvel:
 "The only notable change here is the patch that changes the way we deal
  with spurious errors from the EFI memory attribute protocol. This will
  be backported to v6.6, and is intended to ensure that we will not
  paint ourselves into a corner when we tighten this further in order to
  comply with MS requirements on signed EFI code.

  Note that this protocol does not currently exist in x86 production
  systems in the field, only in Microsoft's fork of OVMF, but it will be
  mandatory for Windows logo certification for x86 PCs in the future.

   - Tighten ELF relocation checks on the RISC-V EFI stub

   - Give up if the new EFI memory attributes protocol fails spuriously
     on x86

   - Take care not to place the kernel in the lowest 16 MB of DRAM on
     x86

   - Omit special purpose EFI memory from memblock

   - Some fixes for the CXL CPER reporting code

   - Make the PE/COFF layout of mixed-mode capable images comply with a
     strict interpretation of the spec"

* tag 'efi-fixes-for-v6.8-1' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi:
  x86/efistub: Use 1:1 file:memory mapping for PE/COFF .compat section
  cxl/trace: Remove unnecessary memcpy's
  cxl/cper: Fix errant CPER prints for CXL events
  efi: Don't add memblocks for soft-reserved memory
  efi: runtime: Fix potential overflow of soft-reserved region size
  efi/libstub: Add one kernel-doc comment
  x86/efistub: Avoid placing the kernel below LOAD_PHYSICAL_ADDR
  x86/efistub: Give up if memory attribute protocol returns an error
  riscv/efistub: Tighten ELF relocation check
  riscv/efistub: Ensure GP-relative addressing is not used

cxl/cper: Fix errant CPER prints for CXL events

2024-02-03T17:31:17+00:00

Jonathan reports that CXL CPER events dump an extra generic error
message.

	{1}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 1
	{1}[Hardware Error]: event severity: recoverable
	{1}[Hardware Error]:  Error 0, type: recoverable
	{1}[Hardware Error]:   section type: unknown, fbcd0a77-c260-417f-85a9-088b1621eba6
	{1}[Hardware Error]:   section length: 0x90
	{1}[Hardware Error]:   00000000: 00000090 00000007 00000000 0d938086 ................
	{1}[Hardware Error]:   00000010: 00100000 00000000 00040000 00000000 ................
	...

CXL events were rerouted though the CXL subsystem for additional
processing.  However, when that work was done it was missed that
cper_estatus_print_section() continued with a generic error message
which is confusing.

Teach CPER print code to ignore printing details of some section types.
Assign the CXL event GUIDs to this set to prevent confusing unknown
prints.

Reported-by: Jonathan Cameron 
Suggested-by: Jonathan Cameron 
Signed-off-by: Ira Weiny 
Reviewed-by: Dave Jiang 
Reviewed-by: Jonathan Cameron 
Reviewed-by: Alison Schofield 
Signed-off-by: Ard Biesheuvel

efi: Don't add memblocks for soft-reserved memory

2024-02-02T18:31:24+00:00

Adding memblocks for soft-reserved regions prevents them from later being
hotplugged in by dax_kmem.

Signed-off-by: Andrew Bresticker 
Signed-off-by: Ard Biesheuvel

efi: runtime: Fix potential overflow of soft-reserved region size

2024-02-02T18:31:24+00:00

md_size will have been narrowed if we have >= 4GB worth of pages in a
soft-reserved region.

Signed-off-by: Andrew Bresticker 
Signed-off-by: Ard Biesheuvel

efi/libstub: Add one kernel-doc comment

2024-01-30T20:44:21+00:00

Add the description of @memory_type to silence the warning:
drivers/firmware/efi/libstub/alignedmem.c:27: warning: Function parameter or struct member 'memory_type' not described in 'efi_allocate_pages_aligned'

Signed-off-by: Yang Li 
[ardb: tweak comment]
Signed-off-by: Ard Biesheuvel

x86/efistub: Avoid placing the kernel below LOAD_PHYSICAL_ADDR

2024-01-30T20:44:21+00:00

The EFI stub's kernel placement logic randomizes the physical placement
of the kernel by taking all available memory into account, and picking a
region at random, based on a random seed.

When KASLR is disabled, this seed is set to 0x0, and this results in the
lowest available region of memory to be selected for loading the kernel,
even if this is below LOAD_PHYSICAL_ADDR. Some of this memory is
typically reserved for the GFP_DMA region, to accommodate masters that
can only access the first 16 MiB of system memory.

Even if such devices are rare these days, we may still end up with a
warning in the kernel log, as reported by Tom:

 swapper/0: page allocation failure: order:10, mode:0xcc1(GFP_KERNEL|GFP_DMA), nodemask=(null),cpuset=/,mems_allowed=0

Fix this by tweaking the random allocation logic to accept a low bound
on the placement, and set it to LOAD_PHYSICAL_ADDR.

Fixes: a1b87d54f4e4 ("x86/efistub: Avoid legacy decompressor when doing EFI boot")
Reported-by: Tom Englund 
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218404
Signed-off-by: Ard Biesheuvel

firmware: microchip: fix wrong sizeof argument

2024-01-29T18:52:11+00:00

response_msg is a pointer to an unsigned int (u32). So passing just
response_msg to sizeof would not print the size of the variable. To get
the size of response_msg we need to pass it as a pointer variable.

Fixes: ec5b0f1193ad ("firmware: microchip: add PolarFire SoC Auto Update support")
Signed-off-by: Samasth Norway Ananda 
Signed-off-by: Conor Dooley