diff options
author | Matt Fleming <matt.fleming@intel.com> | 2013-02-02 15:22:24 +0000 |
---|---|---|
committer | Matt Fleming <matt.fleming@intel.com> | 2013-04-17 08:30:06 +0100 |
commit | 4423d779af2a8f1fbd01aeca5c56522efce7262f (patch) | |
tree | 7a3b39ccdd4022075324545b49237c86d36bfe1a /drivers/firmware/google | |
parent | d5abc7c1050ab2b9556a4bf21626cd74e83cd086 (diff) | |
download | linux-4423d779af2a8f1fbd01aeca5c56522efce7262f.tar.gz linux-4423d779af2a8f1fbd01aeca5c56522efce7262f.tar.bz2 linux-4423d779af2a8f1fbd01aeca5c56522efce7262f.zip |
efivars: Keep a private global pointer to efivars
Some machines have an EFI variable interface that does not conform to
the UEFI specification, e.g. CONFIG_GOOGLE_SMI. Add the necessary code
so that it's only possible to use one implementation of EFI variable
operations at runtime. This allows us to keep a single (file-scope)
global pointer 'struct efivars', which simplifies access. This will
hopefully dissuade developers from accessing the generic operations
struct directly in the future, as was done in the efivarfs and pstore
code, thereby allowing future code to work with both the generic efivar
ops and the google SMI ops.
This may seem like a step backwards in terms of modularity, but we don't
need to track more than one 'struct efivars' at one time. There is no
synchronisation done between multiple EFI variable operations, and
according to Mike no one is using both the generic EFI var ops and
CONFIG_GOOGLE_SMI simultaneously, though a single kernel build _does_
need to able to support both. It also helps to clearly highlight which
functions form the core of the efivars interface - those that require
access to __efivars.
Reviewed-by: Tom Gundersen <teg@jklm.no>
Tested-by: Tom Gundersen <teg@jklm.no>
Acked-by: Mike Waychison <mikew@google.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Diffstat (limited to 'drivers/firmware/google')
0 files changed, 0 insertions, 0 deletions