litmus-rt.git/drivers/firmware/efi/Makefile, branch master

efi/x86: Move x86 back to libstub

2014-11-11T22:23:11+00:00

This reverts commit 84be880560fb, which itself reverted my original
attempt to move x86 from #include'ing .c files from across the tree
to using the EFI stub built as a static library.

The issue that affected the original approach was that splitting
the implementation into several .o files resulted in the variable
'efi_early' becoming a global with external linkage, which under
-fPIC implies that references to it must go through the GOT. However,
dealing with this additional GOT entry turned out to be troublesome
on some EFI implementations. (GCC's visibility=hidden attribute is
supposed to lift this requirement, but it turned out not to work on
the 32-bit build.)

Instead, use a pure getter function to get a reference to efi_early.
This approach results in no additional GOT entries being generated,
so there is no need for any changes in the early GOT handling.

Tested-by: Maarten Lankhorst 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Matt Fleming

Revert "efi/x86: efistub: Move shared dependencies to "

2014-09-23T21:01:55+00:00

This reverts commit f23cf8bd5c1f ("efi/x86: efistub: Move shared
dependencies to ") as well as the x86 parts of commit
f4f75ad5741f ("efi: efistub: Convert into static library").

The road leading to these two reverts is long and winding.

The above two commits were merged during the v3.17 merge window and
turned the common EFI boot stub code into a static library. This
necessitated making some symbols global in the x86 boot stub which
introduced new entries into the early boot GOT.

The problem was that we weren't fixing up the newly created GOT entries
before invoking the EFI boot stub, which sometimes resulted in hangs or
resets. This failure was reported by Maarten on his Macbook pro.

The proposed fix was commit 9cb0e394234d ("x86/efi: Fixup GOT in all
boot code paths"). However, that caused issues for Linus when booting
his Sony Vaio Pro 11. It was subsequently reverted in commit
f3670394c29f.

So that leaves us back with Maarten's Macbook pro not booting.

At this stage in the release cycle the least risky option is to revert
the x86 EFI boot stub to the pre-merge window code structure where we
explicitly #include efi-stub-helper.c instead of linking with the static
library. The arm64 code remains unaffected.

We can take another swing at the x86 parts for v3.18.

Conflicts:
	arch/x86/include/asm/efi.h

Tested-by: Josh Boyer 
Tested-by: Maarten Lankhorst 
Tested-by: Leif Lindholm  [arm64]
Tested-by: Linus Torvalds 
Cc: H. Peter Anvin 
Cc: Ard Biesheuvel ,
Cc: Ingo Molnar 
Signed-off-by: Matt Fleming

efi/reboot: Add generic wrapper around EfiResetSystem()

2014-07-18T20:23:51+00:00

Implement efi_reboot(), which is really just a wrapper around the
EfiResetSystem() EFI runtime service, but it does at least allow us to
funnel all callers through a single location.

It also simplifies the callsites since users no longer need to check to
see whether EFI_RUNTIME_SERVICES are enabled.

Cc: Tony Luck 
Tested-by: Mark Salter 
Signed-off-by: Matt Fleming

efi: efistub: Convert into static library

2014-07-18T20:22:19+00:00

This patch changes both x86 and arm64 efistub implementations
from #including shared .c files under drivers/firmware/efi to
building shared code as a static library.

The x86 code uses a stub built into the boot executable which
uncompresses the kernel at boot time. In this case, the library is
linked into the decompressor.

In the arm64 case, the stub is part of the kernel proper so the library
is linked into the kernel proper as well.

Signed-off-by: Ard Biesheuvel 
Signed-off-by: Matt Fleming

efi/x86: Move UEFI Runtime Services wrappers to generic code

2014-07-07T19:12:53+00:00

In order for other archs (such as arm64) to be able to reuse the virtual
mode function call wrappers, move them to drivers/firmware/efi/runtime-wrappers.c.

Signed-off-by: Ard Biesheuvel 
Signed-off-by: Matt Fleming

Merge tag 'v3.13-rc7' into x86/efi-kexec to resolve conflicts

2014-01-05T11:34:29+00:00

Conflicts:
	arch/x86/platform/efi/efi.c
	drivers/firmware/efi/Kconfig

Signed-off-by: Ingo Molnar

efi: Export EFI runtime memory mapping to sysfs

2013-12-21T15:29:36+00:00

kexec kernel will need exactly same mapping for EFI runtime memory
ranges. Thus here export the runtime ranges mapping to sysfs,
kexec-tools will assemble them and pass to 2nd kernel via setup_data.

Introducing a new directory /sys/firmware/efi/runtime-map just like
/sys/firmware/memmap. Containing below attribute in each file of that
directory:

attribute  num_pages  phys_addr  type  virt_addr

Signed-off-by: Dave Young 
Tested-by: Toshi Kani 
Signed-off-by: Matt Fleming

x86/efi: Don't select EFI from certain special ACPI drivers

2013-12-19T20:32:46+00:00

Commit 7ea6c6c1 ("Move cper.c from drivers/acpi/apei to
drivers/firmware/efi") results in CONFIG_EFI being enabled even
when the user doesn't want this. Since ACPI APEI used to build
fine without UEFI (and as far as I know also has no functional
depency on it), at least in that case using a reverse dependency
is wrong (and a straight one isn't needed).

Whether the same is true for ACPI_EXTLOG I don't know - if there
is a functional dependency, it should depend on EFI rather than
selecting it. It certainly has (currently) no build dependency.

Adjust Kconfig and build logic so that the bad dependency gets
avoided.

Signed-off-by: Jan Beulich 
Acked-by: Tony Luck 
Cc: Matt Fleming 
Link: http://lkml.kernel.org/r/52AF1EBC020000780010DBF9@nat28.tlf.novell.com
Signed-off-by: Ingo Molnar

Move cper.c from drivers/acpi/apei to drivers/firmware/efi

2013-10-31T18:27:04+00:00

cper.c contains code to decode and print "Common Platform Error Records".
Originally added under drivers/acpi/apei because the only user was in that
same directory - but now we have another consumer, and we shouldn't have
to force CONFIG_ACPI_APEI get access to this code.

Since CPER is defined in the UEFI specification - the logical home for
this code is under drivers/firmware/efi/

Acked-by: Matt Fleming 
Acked-by: Ingo Molnar 
Signed-off-by: Tony Luck

efi: split efisubsystem from efivars

2013-04-17T12:27:06+00:00

This registers /sys/firmware/efi/{,systab,efivars/} whenever EFI is enabled
and the system is booted with EFI.

This allows
 *) userspace to check for the existence of /sys/firmware/efi as a way
    to determine whether or it is running on an EFI system.
 *) 'mount -t efivarfs none /sys/firmware/efi/efivars' without manually
    loading any modules.

[ Also, move the efivar API into vars.c and unconditionally compile it.
  This allows us to move efivars.c, which now only contains the sysfs
  variable code, into the firmware/efi directory. Note that the efivars.c
  filename is kept to maintain backwards compatability with the old
  efivars.ko module. With this patch it is now possible for efivarfs
  to be built without CONFIG_EFI_VARS - Matt ]

Cc: Seiji Aguchi 
Cc: Tony Luck 
Cc: Mike Waychison 
Cc: Kay Sievers 
Cc: Jeremy Kerr 
Cc: Matthew Garrett 
Cc: Chun-Yi Lee 
Cc: Andy Whitcroft 
Cc: Tobias Powalowski 
Signed-off-by: Tom Gundersen 
Signed-off-by: Matt Fleming