kernel/linux.git/drivers/firmware/google, branch linux-5.11.y

firmware: gsmi: Drop the use of dma_pool_* API functions

2020-11-09T17:48:06+00:00

GSMI driver uses dma_pool_* API functions for buffer allocation because it requires that the SMI buffers are allocated within 32-bit physical address space. However, this does not work well with IOMMU since there is no real device and hence no domain associated with the device. Since this is not a real device, it does not require any device address(IOVA) for the buffer allocations. The only requirement is to ensure that the physical address allocated to the buffer is within 32-bit physical address space. This is because the buffers have nothing to do with DMA at all. It is required for communication with firmware executing in SMI mode which has access only to the bottom 4GiB of memory. Hence, this change switches to using a SLAB cache created with SLAB_CACHE_DMA32 that guarantees that the allocation happens from the DMA32 memory zone. All calls to dma_pool_* are replaced with kmem_cache_*. In addition to that, all the code for managing the dma_pool for GSMI platform device is dropped. Signed-off-by: Furquan Shaikh Reviewed-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20201022071550.1192947-1-furquan@google.com Signed-off-by: Greg Kroah-Hartman

efi: gsmi: fix false dependency on CONFIG_EFI_VARS

2020-09-29T17:40:57+00:00

The gsmi code does not actually rely on CONFIG_EFI_VARS, since it only uses the efivars abstraction that is included unconditionally when CONFIG_EFI is defined. CONFIG_EFI_VARS controls the inclusion of the code that exposes the sysfs entries, and which has been deprecated for some time. Signed-off-by: Ard Biesheuvel

firmware: google: vpd: Replace zero-length array with flexible-array member

2020-06-16T04:08:21+00:00

There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://github.com/KSPP/linux/issues/21 Signed-off-by: Gustavo A. R. Silva

firmware: google: memconsole: Replace zero-length array with flexible-array member

2020-06-16T04:08:16+00:00

firmware: google: Probe for a GSMI handler in firmware

2020-01-14T20:46:48+00:00

Currently this driver is loaded if the DMI string matches coreboot and has a proper smi_command in the ACPI FADT table, but a GSMI handler in SMM is an optional feature in coreboot. So probe for a SMM GSMI handler before initializing the driver. If the smihandler leaves the calling argument in %eax in the SMM save state untouched that generally means the is no handler for GSMI. Signed-off-by: Arthur Heymans Signed-off-by: Patrick Rudolph Link: https://lore.kernel.org/r/20191118101934.22526-4-patrick.rudolph@9elements.com Signed-off-by: Greg Kroah-Hartman

firmware: google: Unregister driver_info on failure and exit in gsmi

2020-01-14T20:46:48+00:00

Fix a bug where the kernel module couldn't be loaded after unloading, as the platform driver wasn't released on exit. Signed-off-by: Arthur Heymans Signed-off-by: Patrick Rudolph Link: https://lore.kernel.org/r/20191118101934.22526-3-patrick.rudolph@9elements.com Signed-off-by: Greg Kroah-Hartman

firmware: google: Release devices before unregistering the bus

2020-01-14T20:46:48+00:00

Fix a bug where the kernel module can't be loaded after it has been unloaded as the devices are still present and conflicting with the to be created coreboot devices. Signed-off-by: Patrick Rudolph Link: https://lore.kernel.org/r/20191118101934.22526-2-patrick.rudolph@9elements.com Signed-off-by: Greg Kroah-Hartman

firmware: google: increment VPD key_len properly

2019-10-11T06:41:34+00:00

Commit 4b708b7b1a2c ("firmware: google: check if size is valid when decoding VPD data") adds length checks, but the new vpd_decode_entry() function botched the logic -- it adds the key length twice, instead of adding the key and value lengths separately. On my local system, this means vpd.c's vpd_section_create_attribs() hits an error case after the first attribute it parses, since it's no longer looking at the correct offset. With this patch, I'm back to seeing all the correct attributes in /sys/firmware/vpd/... Fixes: 4b708b7b1a2c ("firmware: google: check if size is valid when decoding VPD data") Cc: Cc: Hung-Te Lin Signed-off-by: Brian Norris Reviewed-by: Stephen Boyd Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/20190930214522.240680-1-briannorris@chromium.org Signed-off-by: Greg Kroah-Hartman

firmware: google: check if size is valid when decoding VPD data

2019-09-04T11:31:28+00:00

The VPD implementation from Chromium Vital Product Data project used to parse data from untrusted input without checking if the meta data is invalid or corrupted. For example, the size from decoded content may be negative value, or larger than whole input buffer. Such invalid data may cause buffer overflow. To fix that, the size parameters passed to vpd_decode functions should be changed to unsigned integer (u32) type, and the parsing of entry header should be refactored so every size field is correctly verified before starting to decode. Fixes: ad2ac9d5c5e0 ("firmware: Google VPD: import lib_vpd source files") Signed-off-by: Hung-Te Lin Cc: stable Reviewed-by: Guenter Roeck Reviewed-by: Stephen Boyd Link: https://lore.kernel.org/r/20190830022402.214442-1-hungte@chromium.org Signed-off-by: Greg Kroah-Hartman

Merge 5.2-rc4 into char-misc-next

2019-06-09T07:11:21+00:00

We want the char/misc driver fixes in here as well. Signed-off-by: Greg Kroah-Hartman