linux-stable.git/arch/x86/boot, branch linux-3.7.y

x86, efi: Fix 32-bit EFI handover protocol entry point

2013-02-04T00:27:06+00:00

commit f791620fa7517e1045742c475a7f005db9a634b8 upstream.

If the bootloader calls the EFI handover entry point as a standard function
call, then it'll have a return address on the stack. We need to pop that
before calling efi_main(), or the arguments will all be out of position on
the stack.

Signed-off-by: David Woodhouse 
Link: http://lkml.kernel.org/r/1358513837.2397.247.camel@shinybook.infradead.org
Signed-off-by: H. Peter Anvin 
Cc: Matt Fleming 
Signed-off-by: Greg Kroah-Hartman

x86, efi: Fix display detection in EFI boot stub

2013-02-04T00:27:06+00:00

commit 70a479cbe80296d3113e65cc2f713a5101061daf upstream.

When booting under OVMF we have precisely one GOP device, and it
implements the ConOut protocol.

We break out of the loop when we look at it... and then promptly abort
because 'first_gop' never gets set. We should set first_gop *before*
breaking out of the loop. Yes, it doesn't really mean "first" any more,
but that doesn't matter. It's only a flag to indicate that a suitable
GOP was found.

In fact, we'd do just as well to initialise 'width' to zero in this
function, then just check *that* instead of first_gop. But I'll do the
minimal fix for now (and for stable@).

Signed-off-by: David Woodhouse 
Link: http://lkml.kernel.org/r/1358513837.2397.247.camel@shinybook.infradead.org
Signed-off-by: H. Peter Anvin 
Cc: Matt Fleming 
Signed-off-by: Greg Kroah-Hartman

x86, efi: Fix processor-specific memcpy() build error

2012-11-20T20:52:07+00:00

Building for Athlon/Duron/K7 results in the following build error,

arch/x86/boot/compressed/eboot.o: In function `__constant_memcpy3d':
eboot.c:(.text+0x385): undefined reference to `_mmx_memcpy'
arch/x86/boot/compressed/eboot.o: In function `efi_main':
eboot.c:(.text+0x1a22): undefined reference to `_mmx_memcpy'

because the boot stub code doesn't link with the kernel proper, and
therefore doesn't have access to the 3DNow version of memcpy. So,
follow the example of misc.c and #undef memcpy so that we use the
version provided by misc.c.

See https://bugzilla.kernel.org/show_bug.cgi?id=50391

Reported-by: Al Viro 
Reported-by: Ryan Underwood 
Cc: H. Peter Anvin 
Cc: stable@vger.kernel.org
Signed-off-by: Matt Fleming

x86: remove dummy long from EFI stub

2012-11-20T20:17:48+00:00

Commit 2e064b1 (x86, efi: Fix issue of overlapping .reloc section for
EFI_STUB) removed a dummy reloc added by commit 291f363 (x86, efi: EFI
boot stub support), but forgot to remove the dummy long used by that
reloc.

Reviewed-by: Jordan Justen 
Tested-by: Lee G Rosenbaum 
Cc: "H. Peter Anvin" 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Signed-off-by: Cesar Eduardo Barros 
Signed-off-by: Matt Fleming

x86, boot: Explicitly include autoconf.h for hostprogs

2012-10-14T19:41:28+00:00

The hostprogs need access to the CONFIG_* symbols found in
include/generated/autoconf.h.  But commit abbf1590de22 ("UAPI: Partition
the header include path sets and add uapi/ header directories") replaced
$(LINUXINCLUDE) with $(USERINCLUDE) which doesn't contain the necessary
include paths.

This has the undesirable effect of breaking the EFI boot stub because
the #ifdef CONFIG_EFI_STUB code in arch/x86/boot/tools/build.c is
never compiled.

It should also be noted that because $(USERINCLUDE) isn't exported by
the top-level Makefile it's actually empty in arch/x86/boot/Makefile.

Cc: H. Peter Anvin 
Cc: Ingo Molnar 
Acked-by: David Howells 
Signed-off-by: Matt Fleming 
Signed-off-by: Linus Torvalds

UAPI: Partition the header include path sets and add uapi/ header directories

2012-10-02T17:01:26+00:00

Partition the header include path flags into two sets, one for kernelspace
builds and one for userspace builds.

Add the following directories to build after the ordinary include directories
so that #include will pick up the UAPI header directly if the kernel header
has been moved there.

The userspace set (represented by the USERINCLUDE make variable) contains:

	-I $(srctree)/arch/$(hdr-arch)/include/uapi
	-I arch/$(hdr-arch)/include/generated/uapi
	-I $(srctree)/include/uapi
	-I include/generated/uapi
	-include $(srctree)/include/linux/kconfig.h

and the kernelspace set (represented by the LINUXINCLUDE make variable)
contains:

	-I $(srctree)/arch/$(hdr-arch)/include
	-I arch/$(hdr-arch)/include/generated
	-I $(srctree)/include
	-I include		--- if not building in the source tree

plus everything in the USERINCLUDE set.

Then use USERINCLUDE in building the x86 boot code.

Signed-off-by: David Howells 
Acked-by: Arnd Bergmann 
Acked-by: Thomas Gleixner 
Acked-by: Paul E. McKenney 
Acked-by: Dave Jones

Merge branch 'x86-efi-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2012-10-01T18:08:12+00:00

Pull x86/EFI changes from Ingo Molnar:
 "EFI loader robustness enhancements plus smaller fixes"

* 'x86-efi-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  efi: Fix the ACPI BGRT driver for images located in EFI boot services memory
  efi: Add a function to look up existing IO memory mappings
  efi: Defer freeing boot services memory until after ACPI init
  x86, EFI: Calculate the EFI framebuffer size instead of trusting the firmware
  efifb: Skip DMI checks if the bootloader knows what it's doing
  efi: initialize efi.runtime_version to make query_variable_info/update_capsule workable
  efi: Build EFI stub with EFI-appropriate options
  X86: Improve GOP detection in the EFI boot stub

Merge tag 'v3.6-rc6' into x86/cleanups

2012-09-19T15:32:12+00:00

Merge Linux v3.6-rc6 before applying more cleanups.

Signed-off-by: Ingo Molnar

x86, EFI: Calculate the EFI framebuffer size instead of trusting the firmware

2012-09-17T12:29:24+00:00

Seth Forshee reported that his system was reporting that the EFI framebuffer
stretched from 0x90010000-0xb0010000 despite the GPU's BAR only covering
0x90000000-0x9ffffff. It's safer to calculate this value from the pixel
stride and screen height (values we already depend on) rather than face
potential problems with resource allocation later on.

Signed-off-by: Matthew Garrett 
Tested-by: Seth Forshee 
Signed-off-by: Matt Fleming

efifb: Skip DMI checks if the bootloader knows what it's doing

2012-09-17T12:29:23+00:00

The majority of the DMI checks in efifb are for cases where the bootloader
has provided invalid information. However, on some machines the overrides
may do more harm than good due to configuration differences between machines
with the same machine identifier. It turns out that it's possible for the
bootloader to get the correct information on GOP-based systems, but we
can't guarantee that the kernel's being booted with one that's been updated
to do so. Add support for a capabilities flag that can be set by the
bootloader, and skip the DMI checks in that case. Additionally, set this
flag in the UEFI stub code.

Signed-off-by: Matthew Garrett 
Acked-by: Peter Jones 
Signed-off-by: Matt Fleming