microsoft
/
WSL2-Linux-Kernel
зеркало из https://github.com/microsoft/WSL2-Linux-Kernel.git
1
0
Форкнуть 0
Код Задачи Пакеты Проекты Релизы Вики Активность
WSL2-Linux-Kernel/drivers/firmware/google/Kconfig

78 строки
2.3 KiB
Plaintext
Исходник Постоянная ссылка Обычный вид История

treewide: Add SPDX license identifier - Makefile/Kconfig 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 <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-19 15:07:45 +03:00
# SPDX-License-Identifier: GPL-2.0-only
firmware: google memconsole: Remove useless submenu in Kconfig This patch removes the "Google Firmware Drivers" menu containing a menuconfig entry with the exact same name. The menuconfig is now directly under the "Firmware Drivers" entry. Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-03-28 19:11:25 +03:00
menuconfig GOOGLE_FIRMWARE
Introduce CONFIG_GOOGLE_FIRMWARE In order to keep Google's firmware drivers organized amongst themselves, all Google firmware drivers are gated on CONFIG_GOOGLE_FIRMWARE=y, which defaults to 'n' in the kernel build. Signed-off-by: Mike Waychison <mikew@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-04-30 04:39:31 +04:00
bool "Google Firmware Drivers"
default n
help
firmware: Update Kconfig help text for Google firmware commit d185a3466f0cd5af8f1c5c782c53bc0e6f2e7136 upstream. 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 <jwerner@chromium.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Link: https://lore.kernel.org/r/20180618225540.GD14131@decadent.org.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-06-19 01:55:40 +03:00
These firmware drivers are used by Google servers,
Chromebooks and other devices using coreboot firmware.
If in doubt, say "N".
Introduce CONFIG_GOOGLE_FIRMWARE In order to keep Google's firmware drivers organized amongst themselves, all Google firmware drivers are gated on CONFIG_GOOGLE_FIRMWARE=y, which defaults to 'n' in the kernel build. Signed-off-by: Mike Waychison <mikew@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-04-30 04:39:31 +04:00
firmware: google memconsole: Remove useless submenu in Kconfig This patch removes the "Google Firmware Drivers" menu containing a menuconfig entry with the exact same name. The menuconfig is now directly under the "Firmware Drivers" entry. Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-03-28 19:11:25 +03:00
if GOOGLE_FIRMWARE
Introduce CONFIG_GOOGLE_FIRMWARE In order to keep Google's firmware drivers organized amongst themselves, all Google firmware drivers are gated on CONFIG_GOOGLE_FIRMWARE=y, which defaults to 'n' in the kernel build. Signed-off-by: Mike Waychison <mikew@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-04-30 04:39:31 +04:00
driver: Google EFI SMI The "gsmi" driver bridges userland with firmware specific routines for accessing hardware. Currently, this driver only supports NVRAM and eventlog information. Deprecated functions have been removed from the driver, though their op-codes are left in place so that they are not re-used. This driver works by trampolining into the firmware via the smi_command outlined in the FADT table. Three protocols are used due to various limitations over time, but all are included herein. This driver should only ever load on Google boards, identified by either a "Google, Inc." board vendor string in DMI, or "GOOGLE" in the OEM strings of the FADT ACPI table. This logic happens in gsmi_system_valid(). Signed-off-by: Duncan Laurie <dlaurie@google.com> Signed-off-by: Aaron Durbin <adurbin@google.com> Signed-off-by: Mike Waychison <mikew@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-04-30 04:39:19 +04:00
config GOOGLE_SMI
tristate "SMI interface for Google platforms"
gsmi: Remove autoselected dependency on EFI and EFI_VARS 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 <dlaurie@chromium.org> Reviewed-by: Olof Johansson <olofj@chromium.org> Signed-off-by: Benson Leung <bleung@chromium.org> Signed-off-by: Ben Zhang <benzh@chromium.org> Signed-off-by: Filipe Brandenburger <filbranden@chromium.org> Signed-off-by: Furquan Shaikh <furquan@google.com> Tested-by: Furquan Shaikh <furquan@chromium.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> [zwisler: update changelog for upstream] Signed-off-by: Ross Zwisler <zwisler@google.com> Reviewed-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-10-12 19:04:47 +03:00
depends on X86 && ACPI && DMI
driver: Google EFI SMI The "gsmi" driver bridges userland with firmware specific routines for accessing hardware. Currently, this driver only supports NVRAM and eventlog information. Deprecated functions have been removed from the driver, though their op-codes are left in place so that they are not re-used. This driver works by trampolining into the firmware via the smi_command outlined in the FADT table. Three protocols are used due to various limitations over time, but all are included herein. This driver should only ever load on Google boards, identified by either a "Google, Inc." board vendor string in DMI, or "GOOGLE" in the OEM strings of the FADT ACPI table. This logic happens in gsmi_system_valid(). Signed-off-by: Duncan Laurie <dlaurie@google.com> Signed-off-by: Aaron Durbin <adurbin@google.com> Signed-off-by: Mike Waychison <mikew@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-04-30 04:39:19 +04:00
help
Say Y here if you want to enable SMI callbacks for Google
platforms. This provides an interface for writing to and
efi: gsmi: fix false dependency on CONFIG_EFI_VARS 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 <ardb@kernel.org>
2020-09-23 11:18:31 +03:00
clearing the event log. If CONFIG_EFI is also enabled this
gsmi: Remove autoselected dependency on EFI and EFI_VARS 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 <dlaurie@chromium.org> Reviewed-by: Olof Johansson <olofj@chromium.org> Signed-off-by: Benson Leung <bleung@chromium.org> Signed-off-by: Ben Zhang <benzh@chromium.org> Signed-off-by: Filipe Brandenburger <filbranden@chromium.org> Signed-off-by: Furquan Shaikh <furquan@google.com> Tested-by: Furquan Shaikh <furquan@chromium.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> [zwisler: update changelog for upstream] Signed-off-by: Ross Zwisler <zwisler@google.com> Reviewed-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-10-12 19:04:47 +03:00
driver provides an interface for reading and writing NVRAM
driver: Google EFI SMI The "gsmi" driver bridges userland with firmware specific routines for accessing hardware. Currently, this driver only supports NVRAM and eventlog information. Deprecated functions have been removed from the driver, though their op-codes are left in place so that they are not re-used. This driver works by trampolining into the firmware via the smi_command outlined in the FADT table. Three protocols are used due to various limitations over time, but all are included herein. This driver should only ever load on Google boards, identified by either a "Google, Inc." board vendor string in DMI, or "GOOGLE" in the OEM strings of the FADT ACPI table. This logic happens in gsmi_system_valid(). Signed-off-by: Duncan Laurie <dlaurie@google.com> Signed-off-by: Aaron Durbin <adurbin@google.com> Signed-off-by: Mike Waychison <mikew@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-04-30 04:39:19 +04:00
variables.
driver: Google Memory Console This patch introduces the 'memconsole' driver. Our firmware gives us access to an in-memory log of the firmware's output. This gives us visibility in a data-center of headless machines as to what the firmware is doing. The memory console is found by the driver by finding a header block in the EBDA. The buffer is then copied out, and is exported to userland in the file /sys/firmware/log. Signed-off-by: San Mehat <san@google.com> Signed-off-by: Mike Waychison <mikew@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-04-30 04:39:25 +04:00
firmware: google memconsole: Add coreboot support 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 <vbendeb@chromium.org> Wei-Ning Huang <wnhuang@google.com> Yuji Sasaki <sasakiy@google.com> Duncan Laurie <dlaurie@chromium.org> Julius Werner <jwerner@chromium.org> Brian Norris <briannorris@chromium.org> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-03-28 19:11:27 +03:00
config GOOGLE_COREBOOT_TABLE
firmware: coreboot: Collapse platform drivers into bus core 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 <wnhuang@chromium.org> Cc: Julius Werner <jwerner@chromium.org> Cc: Brian Norris <briannorris@chromium.org> Cc: Samuel Holland <samuel@sholland.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-08-15 23:37:06 +03:00
tristate "Coreboot Table Access"
firmware: google: Properly state IOMEM dependency [ Upstream commit 37fd83916da2e4cae03d350015c82a67b1b334c4 ] 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 <anton.ivanov@cambridgegreys.com> Acked-By: Julius Werner <jwerner@chromium.org> Signed-off-by: David Gow <davidgow@google.com> Link: https://lore.kernel.org/r/20220225041502.1901806-1-davidgow@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-02-25 07:15:02 +03:00
depends on HAS_IOMEM && (ACPI || OF)
firmware: google memconsole: Add coreboot support 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 <vbendeb@chromium.org> Wei-Ning Huang <wnhuang@google.com> Yuji Sasaki <sasakiy@google.com> Duncan Laurie <dlaurie@chromium.org> Julius Werner <jwerner@chromium.org> Brian Norris <briannorris@chromium.org> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-03-28 19:11:27 +03:00
help
This option enables the coreboot_table module, which provides other
firmware: coreboot: Collapse platform drivers into bus core 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 <wnhuang@chromium.org> Cc: Julius Werner <jwerner@chromium.org> Cc: Brian Norris <briannorris@chromium.org> Cc: Samuel Holland <samuel@sholland.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-08-15 23:37:06 +03:00
firmware modules access to the coreboot table. The coreboot table
pointer is accessed through the ACPI "GOOGCB00" object or the
device tree node /firmware/coreboot.
firmware: google memconsole: Add coreboot support 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 <vbendeb@chromium.org> Wei-Ning Huang <wnhuang@google.com> Yuji Sasaki <sasakiy@google.com> Duncan Laurie <dlaurie@chromium.org> Julius Werner <jwerner@chromium.org> Brian Norris <briannorris@chromium.org> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-03-28 19:11:27 +03:00
If unsure say N.
firmware: coreboot: Collapse platform drivers into bus core 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 <wnhuang@chromium.org> Cc: Julius Werner <jwerner@chromium.org> Cc: Brian Norris <briannorris@chromium.org> Cc: Samuel Holland <samuel@sholland.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-08-15 23:37:06 +03:00
config GOOGLE_COREBOOT_TABLE_ACPI
tristate
select GOOGLE_COREBOOT_TABLE
firmware: google memconsole: Add ARM/ARM64 support 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 <wnhuang@chromium.org> Julius Werner <jwerner@chromium.org> Brian Norris <briannorris@chromium.org> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-03-28 19:11:29 +03:00
config GOOGLE_COREBOOT_TABLE_OF
firmware: coreboot: Collapse platform drivers into bus core 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 <wnhuang@chromium.org> Cc: Julius Werner <jwerner@chromium.org> Cc: Brian Norris <briannorris@chromium.org> Cc: Samuel Holland <samuel@sholland.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-08-15 23:37:06 +03:00
tristate
firmware: google memconsole: Add ARM/ARM64 support 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 <wnhuang@chromium.org> Julius Werner <jwerner@chromium.org> Brian Norris <briannorris@chromium.org> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-03-28 19:11:29 +03:00
select GOOGLE_COREBOOT_TABLE
driver: Google Memory Console This patch introduces the 'memconsole' driver. Our firmware gives us access to an in-memory log of the firmware's output. This gives us visibility in a data-center of headless machines as to what the firmware is doing. The memory console is found by the driver by finding a header block in the EBDA. The buffer is then copied out, and is exported to userland in the file /sys/firmware/log. Signed-off-by: San Mehat <san@google.com> Signed-off-by: Mike Waychison <mikew@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-04-30 04:39:25 +04:00
config GOOGLE_MEMCONSOLE
firmware: google memconsole: Move specific EBDA parts This patch splits memconsole.c in 2 parts. One containing the architecture-independent part and the other one containing the EBDA specific part. This prepares the integration of coreboot support for the memconsole. The memconsole driver is now named as memconsole-x86-legacy. Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-03-28 19:11:26 +03:00
tristate
firmware: google memconsole: Add coreboot support 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 <vbendeb@chromium.org> Wei-Ning Huang <wnhuang@google.com> Yuji Sasaki <sasakiy@google.com> Duncan Laurie <dlaurie@chromium.org> Julius Werner <jwerner@chromium.org> Brian Norris <briannorris@chromium.org> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-03-28 19:11:27 +03:00
depends on GOOGLE_MEMCONSOLE_X86_LEGACY || GOOGLE_MEMCONSOLE_COREBOOT
firmware: google memconsole: Move specific EBDA parts This patch splits memconsole.c in 2 parts. One containing the architecture-independent part and the other one containing the EBDA specific part. This prepares the integration of coreboot support for the memconsole. The memconsole driver is now named as memconsole-x86-legacy. Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-03-28 19:11:26 +03:00
config GOOGLE_MEMCONSOLE_X86_LEGACY
tristate "Firmware Memory Console - X86 Legacy support"
depends on X86 && ACPI && DMI
select GOOGLE_MEMCONSOLE
driver: Google Memory Console This patch introduces the 'memconsole' driver. Our firmware gives us access to an in-memory log of the firmware's output. This gives us visibility in a data-center of headless machines as to what the firmware is doing. The memory console is found by the driver by finding a header block in the EBDA. The buffer is then copied out, and is exported to userland in the file /sys/firmware/log. Signed-off-by: San Mehat <san@google.com> Signed-off-by: Mike Waychison <mikew@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-04-30 04:39:25 +04:00
help
This option enables the kernel to search for a firmware log in
the EBDA on Google servers. If found, this log is exported to
userland in the file /sys/firmware/log.
Introduce CONFIG_GOOGLE_FIRMWARE In order to keep Google's firmware drivers organized amongst themselves, all Google firmware drivers are gated on CONFIG_GOOGLE_FIRMWARE=y, which defaults to 'n' in the kernel build. Signed-off-by: Mike Waychison <mikew@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-04-30 04:39:31 +04:00
firmware: coreboot: Add coreboot framebuffer driver Register a simplefb framebuffer when the coreboot table contains a framebuffer entry. Signed-off-by: Samuel Holland <samuel@sholland.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-01-25 04:41:20 +03:00
config GOOGLE_FRAMEBUFFER_COREBOOT
tristate "Coreboot Framebuffer"
depends on FB_SIMPLE
depends on GOOGLE_COREBOOT_TABLE
help
This option enables the kernel to search for a framebuffer in
the coreboot table. If found, it is registered with simplefb.
firmware: google memconsole: Add coreboot support 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 <vbendeb@chromium.org> Wei-Ning Huang <wnhuang@google.com> Yuji Sasaki <sasakiy@google.com> Duncan Laurie <dlaurie@chromium.org> Julius Werner <jwerner@chromium.org> Brian Norris <briannorris@chromium.org> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-03-28 19:11:27 +03:00
config GOOGLE_MEMCONSOLE_COREBOOT
tristate "Firmware Memory Console"
depends on GOOGLE_COREBOOT_TABLE
select GOOGLE_MEMCONSOLE
help
This option enables the kernel to search for a firmware log in
the coreboot table. If found, this log is exported to userland
in the file /sys/firmware/log.
firmware: Google VPD sysfs driver 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 <wnhuang@google.com> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-04-12 19:56:19 +03:00
config GOOGLE_VPD
tristate "Vital Product Data"
depends on GOOGLE_COREBOOT_TABLE
help
This option enables the kernel to expose the content of Google VPD
under /sys/firmware/vpd.
firmware: google memconsole: Remove useless submenu in Kconfig This patch removes the "Google Firmware Drivers" menu containing a menuconfig entry with the exact same name. The menuconfig is now directly under the "Firmware Drivers" entry. Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-03-28 19:11:25 +03:00
endif # GOOGLE_FIRMWARE