<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/arch/x86/kernel/setup.c, branch v3.8</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>efi: Make 'efi_enabled' a function to query EFI facilities</title>
<updated>2013-01-30T19:51:59+00:00</updated>
<author>
<name>Matt Fleming</name>
<email>matt.fleming@intel.com</email>
</author>
<published>2012-11-14T09:42:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=83e68189745ad931c2afd45d8ee3303929233e7f'/>
<id>83e68189745ad931c2afd45d8ee3303929233e7f</id>
<content type='text'>
Originally 'efi_enabled' indicated whether a kernel was booted from
EFI firmware. Over time its semantics have changed, and it now
indicates whether or not we are booted on an EFI machine with
bit-native firmware, e.g. 64-bit kernel with 64-bit firmware.

The immediate motivation for this patch is the bug report at,

    https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557

which details how running a platform driver on an EFI machine that is
designed to run under BIOS can cause the machine to become
bricked. Also, the following report,

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

details how running said driver can also cause Machine Check
Exceptions. Drivers need a new means of detecting whether they're
running on an EFI machine, as sadly the expression,

    if (!efi_enabled)

hasn't been a sufficient condition for quite some time.

Users actually want to query 'efi_enabled' for different reasons -
what they really want access to is the list of available EFI
facilities.

For instance, the x86 reboot code needs to know whether it can invoke
the ResetSystem() function provided by the EFI runtime services, while
the ACPI OSL code wants to know whether the EFI config tables were
mapped successfully. There are also checks in some of the platform
driver code to simply see if they're running on an EFI machine (which
would make it a bad idea to do BIOS-y things).

This patch is a prereq for the samsung-laptop fix patch.

Cc: David Airlie &lt;airlied@linux.ie&gt;
Cc: Corentin Chary &lt;corentincj@iksaif.net&gt;
Cc: Matthew Garrett &lt;mjg59@srcf.ucam.org&gt;
Cc: Dave Jiang &lt;dave.jiang@intel.com&gt;
Cc: Olof Johansson &lt;olof@lixom.net&gt;
Cc: Peter Jones &lt;pjones@redhat.com&gt;
Cc: Colin Ian King &lt;colin.king@canonical.com&gt;
Cc: Steve Langasek &lt;steve.langasek@canonical.com&gt;
Cc: Tony Luck &lt;tony.luck@intel.com&gt;
Cc: Konrad Rzeszutek Wilk &lt;konrad@kernel.org&gt;
Cc: Rafael J. Wysocki &lt;rjw@sisk.pl&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Matt Fleming &lt;matt.fleming@intel.com&gt;
Signed-off-by: H. Peter Anvin &lt;hpa@linux.intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Originally 'efi_enabled' indicated whether a kernel was booted from
EFI firmware. Over time its semantics have changed, and it now
indicates whether or not we are booted on an EFI machine with
bit-native firmware, e.g. 64-bit kernel with 64-bit firmware.

The immediate motivation for this patch is the bug report at,

    https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557

which details how running a platform driver on an EFI machine that is
designed to run under BIOS can cause the machine to become
bricked. Also, the following report,

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

details how running said driver can also cause Machine Check
Exceptions. Drivers need a new means of detecting whether they're
running on an EFI machine, as sadly the expression,

    if (!efi_enabled)

hasn't been a sufficient condition for quite some time.

Users actually want to query 'efi_enabled' for different reasons -
what they really want access to is the list of available EFI
facilities.

For instance, the x86 reboot code needs to know whether it can invoke
the ResetSystem() function provided by the EFI runtime services, while
the ACPI OSL code wants to know whether the EFI config tables were
mapped successfully. There are also checks in some of the platform
driver code to simply see if they're running on an EFI machine (which
would make it a bad idea to do BIOS-y things).

This patch is a prereq for the samsung-laptop fix patch.

Cc: David Airlie &lt;airlied@linux.ie&gt;
Cc: Corentin Chary &lt;corentincj@iksaif.net&gt;
Cc: Matthew Garrett &lt;mjg59@srcf.ucam.org&gt;
Cc: Dave Jiang &lt;dave.jiang@intel.com&gt;
Cc: Olof Johansson &lt;olof@lixom.net&gt;
Cc: Peter Jones &lt;pjones@redhat.com&gt;
Cc: Colin Ian King &lt;colin.king@canonical.com&gt;
Cc: Steve Langasek &lt;steve.langasek@canonical.com&gt;
Cc: Tony Luck &lt;tony.luck@intel.com&gt;
Cc: Konrad Rzeszutek Wilk &lt;konrad@kernel.org&gt;
Cc: Rafael J. Wysocki &lt;rjw@sisk.pl&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Matt Fleming &lt;matt.fleming@intel.com&gt;
Signed-off-by: H. Peter Anvin &lt;hpa@linux.intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>x86/Sandy Bridge: Sandy Bridge workaround depends on CONFIG_PCI</title>
<updated>2013-01-14T04:58:57+00:00</updated>
<author>
<name>H. Peter Anvin</name>
<email>hpa@linux.intel.com</email>
</author>
<published>2013-01-14T04:56:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e43b3cec711a61edf047adf6204d542f3a659ef8'/>
<id>e43b3cec711a61edf047adf6204d542f3a659ef8</id>
<content type='text'>
early_pci_allowed() and read_pci_config_16() are only available if
CONFIG_PCI is defined.

Signed-off-by: H. Peter Anvin &lt;hpa@linux.intel.com&gt;
Cc: Jesse Barnes &lt;jbarnes@virtuousgeek.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
early_pci_allowed() and read_pci_config_16() are only available if
CONFIG_PCI is defined.

Signed-off-by: H. Peter Anvin &lt;hpa@linux.intel.com&gt;
Cc: Jesse Barnes &lt;jbarnes@virtuousgeek.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>x86/Sandy Bridge: mark arrays in __init functions as __initconst</title>
<updated>2013-01-14T04:36:39+00:00</updated>
<author>
<name>H. Peter Anvin</name>
<email>hpa@linux.intel.com</email>
</author>
<published>2013-01-14T04:36:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ab3cd8670e0b3fcde7f029e1503ed3c5138e9571'/>
<id>ab3cd8670e0b3fcde7f029e1503ed3c5138e9571</id>
<content type='text'>
Mark static arrays as __initconst so they get removed when the init
sections are flushed.

Reported-by: Mathias Krause &lt;minipli@googlemail.com&gt;
Link: http://lkml.kernel.org/r/75F4BEE6-CB0E-4426-B40B-697451677738@googlemail.com
Signed-off-by: H. Peter Anvin &lt;hpa@linux.intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Mark static arrays as __initconst so they get removed when the init
sections are flushed.

Reported-by: Mathias Krause &lt;minipli@googlemail.com&gt;
Link: http://lkml.kernel.org/r/75F4BEE6-CB0E-4426-B40B-697451677738@googlemail.com
Signed-off-by: H. Peter Anvin &lt;hpa@linux.intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>x86/Sandy Bridge: reserve pages when integrated graphics is present</title>
<updated>2013-01-11T22:26:38+00:00</updated>
<author>
<name>Jesse Barnes</name>
<email>jbarnes@virtuousgeek.org</email>
</author>
<published>2012-11-14T20:43:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a9acc5365dbda29f7be2884efb63771dc24bd815'/>
<id>a9acc5365dbda29f7be2884efb63771dc24bd815</id>
<content type='text'>
SNB graphics devices have a bug that prevent them from accessing certain
memory ranges, namely anything below 1M and in the pages listed in the
table.  So reserve those at boot if set detect a SNB gfx device on the
CPU to avoid GPU hangs.

Stephane Marchesin had a similar patch to the page allocator awhile
back, but rather than reserving pages up front, it leaked them at
allocation time.

[ hpa: made a number of stylistic changes, marked arrays as static
  const, and made less verbose; use "memblock=debug" for full
  verbosity. ]

Signed-off-by: Jesse Barnes &lt;jbarnes@virtuousgeek.org&gt;
Signed-off-by: H. Peter Anvin &lt;hpa@linux.intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
SNB graphics devices have a bug that prevent them from accessing certain
memory ranges, namely anything below 1M and in the pages listed in the
table.  So reserve those at boot if set detect a SNB gfx device on the
CPU to avoid GPU hangs.

Stephane Marchesin had a similar patch to the page allocator awhile
back, but rather than reserving pages up front, it leaked them at
allocation time.

[ hpa: made a number of stylistic changes, marked arrays as static
  const, and made less verbose; use "memblock=debug" for full
  verbosity. ]

Signed-off-by: Jesse Barnes &lt;jbarnes@virtuousgeek.org&gt;
Signed-off-by: H. Peter Anvin &lt;hpa@linux.intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'x86-acpi-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip</title>
<updated>2012-12-14T18:03:23+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2012-12-14T18:03:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=18dd0bf22b6f0c1bd5e4e813a42245ed86ec57b6'/>
<id>18dd0bf22b6f0c1bd5e4e813a42245ed86ec57b6</id>
<content type='text'>
Pull x86 ACPI update from Peter Anvin:
 "This is a patchset which didn't make the last merge window.  It adds a
  debugging capability to feed ACPI tables via the initramfs.

  On a grander scope, it formalizes using the initramfs protocol for
  feeding arbitrary blobs which need to be accessed early to the kernel:
  they are fed first in the initramfs blob (lots of bootloaders can
  concatenate this at boot time, others can use a single file) in an
  uncompressed cpio archive using filenames starting with "kernel/".

  The ACPI maintainers requested that this patchset be fed via the x86
  tree rather than the ACPI tree as the footprint in the general x86
  code is much bigger than in the ACPI code proper."

* 'x86-acpi-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  X86 ACPI: Use #ifdef not #if for CONFIG_X86 check
  ACPI: Fix build when disabled
  ACPI: Document ACPI table overriding via initrd
  ACPI: Create acpi_table_taint() function to avoid code duplication
  ACPI: Implement physical address table override
  ACPI: Store valid ACPI tables passed via early initrd in reserved memblock areas
  x86, acpi: Introduce x86 arch specific arch_reserve_mem_area() for e820 handling
  lib: Add early cpio decoder
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull x86 ACPI update from Peter Anvin:
 "This is a patchset which didn't make the last merge window.  It adds a
  debugging capability to feed ACPI tables via the initramfs.

  On a grander scope, it formalizes using the initramfs protocol for
  feeding arbitrary blobs which need to be accessed early to the kernel:
  they are fed first in the initramfs blob (lots of bootloaders can
  concatenate this at boot time, others can use a single file) in an
  uncompressed cpio archive using filenames starting with "kernel/".

  The ACPI maintainers requested that this patchset be fed via the x86
  tree rather than the ACPI tree as the footprint in the general x86
  code is much bigger than in the ACPI code proper."

* 'x86-acpi-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  X86 ACPI: Use #ifdef not #if for CONFIG_X86 check
  ACPI: Fix build when disabled
  ACPI: Document ACPI table overriding via initrd
  ACPI: Create acpi_table_taint() function to avoid code duplication
  ACPI: Implement physical address table override
  ACPI: Store valid ACPI tables passed via early initrd in reserved memblock areas
  x86, acpi: Introduce x86 arch specific arch_reserve_mem_area() for e820 handling
  lib: Add early cpio decoder
</pre>
</div>
</content>
</entry>
<entry>
<title>x86: Use PCI setup data</title>
<updated>2012-12-05T21:38:26+00:00</updated>
<author>
<name>Matthew Garrett</name>
<email>mjg@redhat.com</email>
</author>
<published>2012-12-05T21:33:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f9a37be0f02a943d63e3346b19f9c9d8d91826cb'/>
<id>f9a37be0f02a943d63e3346b19f9c9d8d91826cb</id>
<content type='text'>
EFI can provide PCI ROMs out of band via boot services, which may not be
available after boot. Add support for using the data handed off to us by
the boot stub or bootloader.

[bhelgaas: added Seth's boot_params section mismatch fix]
[bhelgaas: drop "boot_params.hdr.version &lt; 0x0209" test]
Signed-off-by: Matthew Garrett &lt;mjg@redhat.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Tested-by: Seth Forshee &lt;seth.forshee@canonical.com&gt;</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
EFI can provide PCI ROMs out of band via boot services, which may not be
available after boot. Add support for using the data handed off to us by
the boot stub or bootloader.

[bhelgaas: added Seth's boot_params section mismatch fix]
[bhelgaas: drop "boot_params.hdr.version &lt; 0x0209" test]
Signed-off-by: Matthew Garrett &lt;mjg@redhat.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Tested-by: Seth Forshee &lt;seth.forshee@canonical.com&gt;</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'efi-for-3.7' of git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi into x86/urgent</title>
<updated>2012-10-26T08:17:38+00:00</updated>
<author>
<name>Ingo Molnar</name>
<email>mingo@kernel.org</email>
</author>
<published>2012-10-26T08:17:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=8b724e2a12d553cad8ad412846511c783a92d25e'/>
<id>8b724e2a12d553cad8ad412846511c783a92d25e</id>
<content type='text'>
Pull EFI fixes from Matt Fleming:

 "Fix oops with EFI variables on mixed 32/64-bit firmware/kernels and
  document EFI git repository location on kernel.org."

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

Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull EFI fixes from Matt Fleming:

 "Fix oops with EFI variables on mixed 32/64-bit firmware/kernels and
  document EFI git repository location on kernel.org."

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

Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>x86: efi: Turn off efi_enabled after setup on mixed fw/kernel</title>
<updated>2012-10-25T18:09:40+00:00</updated>
<author>
<name>Olof Johansson</name>
<email>olof@lixom.net</email>
</author>
<published>2012-10-24T17:00:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=5189c2a7c7769ee9d037d76c1a7b8550ccf3481c'/>
<id>5189c2a7c7769ee9d037d76c1a7b8550ccf3481c</id>
<content type='text'>
When 32-bit EFI is used with 64-bit kernel (or vice versa), turn off
efi_enabled once setup is done. Beyond setup, it is normally used to
determine if runtime services are available and we will have none.

This will resolve issues stemming from efivars modprobe panicking on a
32/64-bit setup, as well as some reboot issues on similar setups.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=45991

Reported-by: Marko Kohtala &lt;marko.kohtala@gmail.com&gt;
Reported-by: Maxim Kammerer &lt;mk@dee.su&gt;
Signed-off-by: Olof Johansson &lt;olof@lixom.net&gt;
Acked-by: Maarten Lankhorst &lt;maarten.lankhorst@canonical.com&gt;
Cc: stable@kernel.org # 3.4 - 3.6
Cc: Matthew Garrett &lt;mjg@redhat.com&gt;
Signed-off-by: Matt Fleming &lt;matt.fleming@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When 32-bit EFI is used with 64-bit kernel (or vice versa), turn off
efi_enabled once setup is done. Beyond setup, it is normally used to
determine if runtime services are available and we will have none.

This will resolve issues stemming from efivars modprobe panicking on a
32/64-bit setup, as well as some reboot issues on similar setups.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=45991

Reported-by: Marko Kohtala &lt;marko.kohtala@gmail.com&gt;
Reported-by: Maxim Kammerer &lt;mk@dee.su&gt;
Signed-off-by: Olof Johansson &lt;olof@lixom.net&gt;
Acked-by: Maarten Lankhorst &lt;maarten.lankhorst@canonical.com&gt;
Cc: stable@kernel.org # 3.4 - 3.6
Cc: Matthew Garrett &lt;mjg@redhat.com&gt;
Signed-off-by: Matt Fleming &lt;matt.fleming@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>x86, mm: Use memblock memory loop instead of e820_RAM</title>
<updated>2012-10-24T18:52:36+00:00</updated>
<author>
<name>Yinghai Lu</name>
<email>yinghai@kernel.org</email>
</author>
<published>2012-10-22T23:35:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=1f2ff682ac951ed82cc043cf140d2851084512df'/>
<id>1f2ff682ac951ed82cc043cf140d2851084512df</id>
<content type='text'>
We need to handle E820_RAM and E820_RESERVED_KERNEL at the same time.

Also memblock has page aligned range for ram, so we could avoid mapping
partial pages.

Signed-off-by: Yinghai Lu &lt;yinghai@kernel.org&gt;
Link: http://lkml.kernel.org/r/CAE9FiQVZirvaBMFYRfXMmWEcHbKSicQEHz4VAwUv0xFCk51ZNw@mail.gmail.com
Acked-by: Jacob Shin &lt;jacob.shin@amd.com&gt;
Signed-off-by: H. Peter Anvin &lt;hpa@linux.intel.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We need to handle E820_RAM and E820_RESERVED_KERNEL at the same time.

Also memblock has page aligned range for ram, so we could avoid mapping
partial pages.

Signed-off-by: Yinghai Lu &lt;yinghai@kernel.org&gt;
Link: http://lkml.kernel.org/r/CAE9FiQVZirvaBMFYRfXMmWEcHbKSicQEHz4VAwUv0xFCk51ZNw@mail.gmail.com
Acked-by: Jacob Shin &lt;jacob.shin@amd.com&gt;
Signed-off-by: H. Peter Anvin &lt;hpa@linux.intel.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge commit '5bc66170dc486556a1e36fd384463536573f4b82' into x86/urgent</title>
<updated>2012-10-19T14:55:09+00:00</updated>
<author>
<name>H. Peter Anvin</name>
<email>hpa@linux.intel.com</email>
</author>
<published>2012-10-19T14:54:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=4533d86270d7986e00594495dde9a109d6be27ae'/>
<id>4533d86270d7986e00594495dde9a109d6be27ae</id>
<content type='text'>
From Borislav Petkov &lt;bp@amd64.org&gt;:

Below is a RAS fix which reverts the addition of a sysfs attribute
which we agreed is not needed, post-factum. And this should go in now
because that sysfs attribute is going to end up in 3.7 otherwise and
thus exposed to userspace; removing it then would be a lot harder.

This is done as a merge rather than a simple patch/cherry-pick since
the baseline for this patch was not in the previous x86/urgent.

Signed-off-by: H. Peter Anvin &lt;hpa@linux.intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
From Borislav Petkov &lt;bp@amd64.org&gt;:

Below is a RAS fix which reverts the addition of a sysfs attribute
which we agreed is not needed, post-factum. And this should go in now
because that sysfs attribute is going to end up in 3.7 otherwise and
thus exposed to userspace; removing it then would be a lot harder.

This is done as a merge rather than a simple patch/cherry-pick since
the baseline for this patch was not in the previous x86/urgent.

Signed-off-by: H. Peter Anvin &lt;hpa@linux.intel.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
