This patch imports lib_vpd.h and vpd_decode.c from the Chromium Vital
Product Data project.

This library is used to parse VPD sections obtained from coreboot table
entries describing Chromebook devices product data. Only the sections of
type VPD_TYPE_STRING are decoded.

The VPD string sections in the coreboot tables contain the type (1 byte
set to 0x01 for strings), the key length, the key ascii array, the value
length, and the value ascii array. The key and value arrays are not null
terminated.
Signed-off-by: NWei-Ning Huang <wnhuang@google.com>
Signed-off-by: NThierry Escande <thierry.escande@collabora.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NThierry Escande <thierry.escande@collabora.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NThierry Escande <thierry.escande@collabora.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NThierry Escande <thierry.escande@collabora.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NThierry Escande <thierry.escande@collabora.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The dma_pool_destroy() function tests whether its argument is NULL
and then returns immediately. Thus the test around the call is not needed.

This issue was detected by using the Coccinelle software.
Signed-off-by: NMarkus Elfring <elfring@users.sourceforge.net>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Julia Lawall <julia.lawall@lip6.fr>
Cc: Mike Waychison <mikew@google.com>
Cc: Michel Lespinasse <walken@google.com>
Signed-off-by: NMatt Fleming <matt@codeblueprint.co.uk>

The google memconsole driver is currently broken upstream, as it tries
to read memory that is described as reserved in /proc/iomem, by
dereferencing a pointer obtained through phys_to_virt(). This triggers
a kernel fault as such regions are unmapped after early boot.

The proper workaround is to use ioremap_cache() / iounmap() around such
accesses.

As some unrelated changes, I also converted some printks to use pr_info()
and added some missing __init annotations.

Tested: booted dbg build, verified I could read /sys/firmware/log
Signed-off-by: NMichel Lespinasse <walken@google.com>
Acked-by: NMike Waychison <mikew@google.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Starting in commit e14ab23d,
efivars_sysfs_init() is called both by itself as an init function,
and by drivers/firmware/google/gsmi.c gsmi_init().

This results in runtime warnings such as the following:
[    5.651330] WARNING: at fs/sysfs/dir.c:530 sysfs_add_one+0xbd/0xe0()
[    5.657699] sysfs: cannot create duplicate filename '/firmware/gsmi/vars'

Fixing this by removing the redundant efivars_sysfs_init() call in
gsmi_init().

Tested: booted, checked that /firmware/gsmi/vars was still present and
showed the expected contents.
Signed-off-by: NMichel Lespinasse <walken@google.com>
Acked-by: NMatt Fleming <matt.fleming@intel.com>
Acked-by: NMike Waychison <mikew@google.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The GOOGLE_SMI Kconfig symbol depends on DMI and selects EFI.  This
causes problems on other archs when introducing DMI support that depends
on EFI, as it results in a recursive dependency:

  arch/arm/Kconfig:1845:error: recursive dependency detected!
  arch/arm/Kconfig:1845:	symbol DMI depends on EFI

Fix by changing the 'select EFI' to a 'depends on EFI'.
Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Cc: David Rientjes <rientjes@google.com>
Acked-by: NMike Waychison <mikew@google.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This driver doesn't need to directly access DMA masks if it uses the
platform_device_register_full() API rather than
platform_device_register_simple() - the former function can initialize
the DMA mask appropriately.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The use of strict_strtoul() is not preferred, because strict_strtoul() is
obsolete.  Thus, kstrtoul() should be used.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Cc: Matt Fleming <matt.fleming@intel.com>
Cc: Tom Gundersen <teg@jklm.no>
Cc: Mike Waychison <mikew@google.com>
Acked-by: NMike Waychison <mikew@google.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

There isn't really a formal interface for dealing with EFI variables
or struct efivar_entry. Historically, this has led to various bits of
code directly accessing the generic EFI variable ops, which inherently
ties it to specific EFI variable operations instead of indirectly
using whatever ops were registered with register_efivars(). This lead
to the efivarfs code only working with the generic EFI variable ops
and not CONFIG_GOOGLE_SMI.

Encapsulate everything that needs to access '__efivars' inside an
efivar_entry_* API and use the new API in the pstore, sysfs and
efivarfs code.

Much of the efivars code had to be rewritten to use this new API. For
instance, it is now up to the users of the API to build the initial
list of EFI variables in their efivar_init() callback function. The
variable list needs to be passed to efivar_init() which allows us to
keep work arounds for things like implementation bugs in
GetNextVariable() in a central location.

Allowing users of the API to use a callback function to build the list
greatly benefits the efivarfs code which needs to allocate inodes and
dentries for every variable.  It previously did this in a racy way
because the code ran without holding the variable spinlock. Both the
sysfs and efivarfs code maintain their own lists which means the two
interfaces can be running simultaneously without interference, though
it should be noted that because no synchronisation is performed it is
very easy to create inconsistencies. efibootmgr doesn't currently use
efivarfs and users are likely to also require the old sysfs interface,
so it makes sense to allow both to be built.
Reviewed-by: NTom Gundersen <teg@jklm.no>
Tested-by: NTom Gundersen <teg@jklm.no>
Cc: Seiji Aguchi <seiji.aguchi@hds.com>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Jeremy Kerr <jk@ozlabs.org>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Mike Waychison <mikew@google.com>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>

There are currently two implementations of the utf16 string functions.
Somewhat confusingly, they've got different names.

Centralise the functions in efi.h.
Reviewed-by: NTom Gundersen <teg@jklm.no>
Tested-by: NTom Gundersen <teg@jklm.no>
Reviewed-by: NMike Waychison <mikew@google.com>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>

Use min_t() macro instead of min() to fix a build warning:

  CC      drivers/firmware/google/gsmi.o
drivers/firmware/google/gsmi.c: In function ‘gsmi_get_variable’:
drivers/firmware/google/gsmi.c:348: warning: comparison of distinct
pointer types lacks a cast
Signed-off-by: NMaxin B. John <maxin.john@gmail.com>
Acked-By: NMike Waychison <mikew@google.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This file really needs the full module.h header file present, but
was just getting it implicitly before.  Fix it up in advance so we
avoid build failures once the cleanup commit is present.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>

Modify function parameter type to match expected type.  Fixes a
build warning:

drivers/firmware/google/gsmi.c:473: warning: initialization from incompatible pointer type
Signed-off-by: NRandy Dunlap <rdunlap@xenotime.net>
Cc: Mike Waychison <mikew@google.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch removes sysfs entries in gsmi_exit() and gsmi_init() error path.

Also move the driver successfully loaded message to the end of gsmi_init()
and return proper error if register_efivars() fails.
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

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: NRandy Dunlap <randy.dunlap@oracle.com>
Acked-by: NMike Waychison <mikew@google.com>
Signed-off-by: NGreg 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: NMike Waychison <mikew@google.com>
Signed-off-by: NGreg 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: NSan Mehat <san@google.com>
Signed-off-by: NMike Waychison <mikew@google.com>
Signed-off-by: NGreg 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: NDuncan Laurie <dlaurie@google.com>
Signed-off-by: NAaron Durbin <adurbin@google.com>
Signed-off-by: NMike Waychison <mikew@google.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>