Is it meaningful/useful to enable EFI_VARS but not EFI?
That's what GOOGLE_SMI does. Make it enable EFI also.
Fixes this kconfig dependency warning:
warning: (GOOGLE_SMI) selects EFI_VARS which has unmet direct dependencies (EFI)
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Acked-by: Mike Waychison <mikew@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
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>
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>
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>
Randy Dunlap