linux-dev/drivers/firmware/google/Kconfig, branch master

firmware: google: Properly state IOMEM dependency

2022-03-18T13:18:15Z

The Google Coreboot implementation requires IOMEM functions (memmremap, memunmap, devm_memremap), but does not specify this is its Kconfig. This results in build errors when HAS_IOMEM is not set, such as on some UML configurations: /usr/bin/ld: drivers/firmware/google/coreboot_table.o: in function `coreboot_table_probe': coreboot_table.c:(.text+0x311): undefined reference to `memremap' /usr/bin/ld: coreboot_table.c:(.text+0x34e): undefined reference to `memunmap' /usr/bin/ld: drivers/firmware/google/memconsole-coreboot.o: in function `memconsole_probe': memconsole-coreboot.c:(.text+0x12d): undefined reference to `memremap' /usr/bin/ld: memconsole-coreboot.c:(.text+0x17e): undefined reference to `devm_memremap' /usr/bin/ld: memconsole-coreboot.c:(.text+0x191): undefined reference to `memunmap' /usr/bin/ld: drivers/firmware/google/vpd.o: in function `vpd_section_destroy.isra.0': vpd.c:(.text+0x300): undefined reference to `memunmap' /usr/bin/ld: drivers/firmware/google/vpd.o: in function `vpd_section_init': vpd.c:(.text+0x382): undefined reference to `memremap' /usr/bin/ld: vpd.c:(.text+0x459): undefined reference to `memunmap' /usr/bin/ld: drivers/firmware/google/vpd.o: in function `vpd_probe': vpd.c:(.text+0x59d): undefined reference to `memremap' /usr/bin/ld: vpd.c:(.text+0x5d3): undefined reference to `memunmap' collect2: error: ld returned 1 exit status Fixes: a28aad66da8b ("firmware: coreboot: Collapse platform drivers into bus core") Acked-By: anton ivanov Acked-By: Julius Werner Signed-off-by: David Gow Link: https://lore.kernel.org/r/20220225041502.1901806-1-davidgow@google.com Signed-off-by: Greg Kroah-Hartman

firmware: Update Kconfig help text for Google firmware

2021-12-21T09:12:31Z

The help text for GOOGLE_FIRMWARE states that it should only be enabled when building a kernel for Google's own servers. However, many of the drivers dependent on it are also useful on Chromebooks or on any platform using coreboot. Update the help text to reflect this double duty. Fixes: d384d6f43d1e ("firmware: google memconsole: Add coreboot support") Reviewed-by: Julius Werner Signed-off-by: Ben Hutchings Link: https://lore.kernel.org/r/20180618225540.GD14131@decadent.org.uk Signed-off-by: Greg Kroah-Hartman

efi: gsmi: fix false dependency on CONFIG_EFI_VARS

2020-09-29T17:40:57Z

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

treewide: Add SPDX license identifier - Makefile/Kconfig

2019-05-21T08:50:46Z

Add SPDX license identifiers to all Make/Kconfig files which: - Have no license information of any form These files fall under the project license, GPL v2 only. The resulting SPDX license identifier is: GPL-2.0-only Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman

gsmi: Remove autoselected dependency on EFI and EFI_VARS

2018-10-15T18:32:26Z

Instead of selecting EFI and EFI_VARS automatically when GSMI is enabled let that portion of the driver be conditionally compiled if EFI and EFI_VARS are enabled. This allows the rest of the driver (specifically event log) to be used if EFI_VARS is not enabled. To test: 1) verify that EFI_VARS is not automatically selected when CONFIG_GOOGLE_GSMI is enabled 2) verify that the kernel boots on Link and that GSMI event log is still available and functional 3) specifically boot the kernel on Alex to ensure it does not try to load efivars and that gsmi also does not load because it is not in the supported DMI table Signed-off-by: Duncan Laurie Reviewed-by: Olof Johansson Signed-off-by: Benson Leung Signed-off-by: Ben Zhang Signed-off-by: Filipe Brandenburger Signed-off-by: Furquan Shaikh Tested-by: Furquan Shaikh Reviewed-by: Aaron Durbin [zwisler: update changelog for upstream] Signed-off-by: Ross Zwisler Reviewed-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman

firmware: coreboot: Collapse platform drivers into bus core

2018-09-14T13:37:23Z

The DT based and ACPI based platform drivers here do the same thing; map some memory and hand it over to the coreboot bus to populate devices. The only major difference is that the DT based driver doesn't map the coreboot table header to figure out how large of a region to map for the whole coreboot table and it uses of_iomap() instead of ioremap_cache(). A cached or non-cached mapping shouldn't matter here and mapping some smaller region first before mapping the whole table is just more work but should be OK. In the end, we can remove two files and combine the code all in one place making it easier to reason about things. We leave the old Kconfigs in place for a little while longer but make them hidden and select the previously hidden config option. This way users can upgrade without having to know to reselect this config in the future. Later on we can remove the old hidden configs. Cc: Wei-Ning Huang Cc: Julius Werner Cc: Brian Norris Cc: Samuel Holland Signed-off-by: Stephen Boyd Reviewed-by: Julius Werner Signed-off-by: Greg Kroah-Hartman

firmware: coreboot: Add coreboot framebuffer driver

2018-04-23T11:37:19Z

Register a simplefb framebuffer when the coreboot table contains a framebuffer entry. Signed-off-by: Samuel Holland Signed-off-by: Greg Kroah-Hartman

firmware: Google VPD sysfs driver

2017-04-18T16:05:23Z

This patch introduces the Google Vital Product Data driver. This driver reads Vital Product Data from coreboot tables and then creates the corresponding sysfs entries under /sys/firmware/vpd to provide easy access for userspace programs (does not require flashrom). The sysfs is structured as follow: /sys/firmware/vpd |-- ro | |-- key1 | `-- key2 |-- ro_raw |-- rw | `-- key1 `-- rw_raw Where ro_raw and rw_raw contain the raw VPD partition. The files under ro and rw correspond to the key name in the VPD and the the file content is the value for the key. Signed-off-by: Wei-Ning Huang Signed-off-by: Thierry Escande Signed-off-by: Greg Kroah-Hartman

firmware: google memconsole: Add ARM/ARM64 support

2017-04-08T16:05:36Z

This patch expands the Google firmware memory console driver to also work on certain tree based platforms running coreboot, such as ARM/ARM64 Chromebooks. This patch now adds another path to find the coreboot table through the device tree. In order to find that, a second level bootloader must have installed the 'coreboot' compatible device tree node that describes its base address and size. This patch is a rework/split/merge of patches from the chromeos v4.4 kernel tree originally authored by: Wei-Ning Huang Julius Werner Brian Norris Signed-off-by: Thierry Escande Signed-off-by: Greg Kroah-Hartman

firmware: google memconsole: Add coreboot support

2017-04-08T16:05:36Z

Coreboot (http://www.coreboot.org) allows to save the firmware console output in a memory buffer. With this patch, the address of this memory buffer is obtained from coreboot tables on x86 chromebook devices declaring an ACPI device with name matching GOOGCB00 or BOOT0000. If the memconsole-coreboot driver is able to find the coreboot table, the memconsole driver sets the cbmem_console address and initializes the memconsole sysfs entries. The coreboot_table-acpi driver is responsible for setting the address of the coreboot table header when probed. If this address is not yet set when memconsole-coreboot is probed, then the probe is deferred by returning -EPROBE_DEFER. This patch is a rework/split/merge of patches from the chromeos v4.4 kernel tree originally authored by: Vadim Bendebury Wei-Ning Huang Yuji Sasaki Duncan Laurie Julius Werner Brian Norris Signed-off-by: Thierry Escande Signed-off-by: Greg Kroah-Hartman