<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/drivers/firmware/efi/Kconfig, branch linux-4.9.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.9.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.9.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2020-07-09T07:35:57Z</updated>
<entry>
<title>efi: Make it possible to disable efivar_ssdt entirely</title>
<updated>2020-07-09T07:35:57Z</updated>
<author>
<name>Peter Jones</name>
</author>
<published>2020-06-15T20:24:08Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=1535f26e259dc07209f0a07bda369311ade5951b'/>
<id>urn:sha1:1535f26e259dc07209f0a07bda369311ade5951b</id>
<content type='text'>
commit 435d1a471598752446a72ad1201b3c980526d869 upstream.

In most cases, such as CONFIG_ACPI_CUSTOM_DSDT and
CONFIG_ACPI_TABLE_UPGRADE, boot-time modifications to firmware tables
are tied to specific Kconfig options.  Currently this is not the case
for modifying the ACPI SSDT via the efivar_ssdt kernel command line
option and associated EFI variable.

This patch adds CONFIG_EFI_CUSTOM_SSDT_OVERLAYS, which defaults
disabled, in order to allow enabling or disabling that feature during
the build.

Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Peter Jones &lt;pjones@redhat.com&gt;
Link: https://lore.kernel.org/r/20200615202408.2242614-1-pjones@redhat.com
Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>efi: Add efi_test driver for exporting UEFI runtime service interfaces</title>
<updated>2016-09-09T15:08:53Z</updated>
<author>
<name>Ivan Hu</name>
</author>
<published>2016-08-25T03:15:31Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=ff6301dabc3ca20ab8f50f8d0252ac05da610d89'/>
<id>urn:sha1:ff6301dabc3ca20ab8f50f8d0252ac05da610d89</id>
<content type='text'>
This driver is used by the Firmware Test Suite (FWTS) for testing the UEFI
runtime interfaces readiness of the firmware.

This driver exports UEFI runtime service interfaces into userspace,
which allows to use and test UEFI runtime services provided by the
firmware.

This driver uses the efi.&lt;service&gt; function pointers directly instead of
going through the efivar API to allow for direct testing of the UEFI
runtime service interfaces provided by the firmware.

Details for FWTS are available from,
&lt;https://wiki.ubuntu.com/FirmwareTestSuite&gt;

Signed-off-by: Ivan Hu &lt;ivan.hu@canonical.com&gt;
Cc: joeyli &lt;jlee@suse.com&gt;
Cc: Ricardo Neri &lt;ricardo.neri-calderon@linux.intel.com&gt;
Cc: Ard Biesheuvel &lt;ard.biesheuvel@linaro.org&gt;
Signed-off-by: Matt Fleming &lt;matt@codeblueprint.co.uk&gt;
</content>
</entry>
<entry>
<title>efi: Add misc char driver interface to update EFI firmware</title>
<updated>2016-04-28T09:34:05Z</updated>
<author>
<name>Kweh, Hock Leong</name>
</author>
<published>2016-04-25T20:07:01Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=65117f1aa1b2d145fd5ca376bde642794d0aae1b'/>
<id>urn:sha1:65117f1aa1b2d145fd5ca376bde642794d0aae1b</id>
<content type='text'>
This patch introduces a kernel module to expose a capsule loader
interface (misc char device file note) for users to upload capsule
binaries.

Example:

  cat firmware.bin &gt; /dev/efi_capsule_loader

Any upload error will be returned while doing "cat" through file
operation write() function call.

Signed-off-by: Kweh, Hock Leong &lt;hock.leong.kweh@intel.com&gt;
[ Update comments and Kconfig text ]
Signed-off-by: Matt Fleming &lt;matt@codeblueprint.co.uk&gt;
Reviewed-by: Bryan O'Donoghue &lt;pure.logic@nexus-software.ie&gt;
Acked-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Cc: Andy Lutomirski &lt;luto@amacapital.net&gt;
Cc: Ard Biesheuvel &lt;ard.biesheuvel@linaro.org&gt;
Cc: Borislav Petkov &lt;bp@alien8.de&gt;
Cc: Peter Jones &lt;pjones@redhat.com&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Sam Protsenko &lt;semen.protsenko@linaro.org&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: joeyli &lt;jlee@suse.com&gt;
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/1461614832-17633-30-git-send-email-matt@codeblueprint.co.uk
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
</content>
</entry>
<entry>
<title>efibc: Add EFI Bootloader Control module</title>
<updated>2016-04-28T09:34:02Z</updated>
<author>
<name>Compostella, Jeremy</name>
</author>
<published>2016-04-25T20:06:57Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=06f7d4a1618dbb086e738c93cd1ef416ab01027d'/>
<id>urn:sha1:06f7d4a1618dbb086e738c93cd1ef416ab01027d</id>
<content type='text'>
This module installs a reboot callback, such that if reboot() is invoked
with a string argument NNN, "NNN" is copied to the "LoaderEntryOneShot"
EFI variable, to be read by the bootloader.

If the string matches one of the boot labels defined in its configuration,
the bootloader will boot once to that label.  The "LoaderEntryRebootReason"
EFI variable is set with the reboot reason: "reboot", "shutdown".

The bootloader reads this reboot reason and takes particular action
according to its policy.

There are reboot implementations that do "reboot &lt;reason&gt;", such as
Android's reboot command and Upstart's reboot replacement, which pass
the reason as an argument to the reboot syscall.  There is no
platform-agnostic way how those could be modified to pass the reason
to the bootloader, regardless of platform or bootloader.

Signed-off-by: Jeremy Compostella &lt;jeremy.compostella@intel.com&gt;
Signed-off-by: Matt Fleming &lt;matt@codeblueprint.co.uk&gt;
Cc: Ard Biesheuvel &lt;ard.biesheuvel@linaro.org&gt;
Cc: Borislav Petkov &lt;bp@alien8.de&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Stefan Stanacar &lt;stefan.stanacar@intel.com&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/1461614832-17633-26-git-send-email-matt@codeblueprint.co.uk
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
</content>
</entry>
<entry>
<title>Merge tag 'efi-next' of git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi into core/efi</title>
<updated>2015-10-14T14:51:34Z</updated>
<author>
<name>Ingo Molnar</name>
</author>
<published>2015-10-14T14:05:40Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=790a2ee2427852cff50993c98f15ed88511e9af0'/>
<id>urn:sha1:790a2ee2427852cff50993c98f15ed88511e9af0</id>
<content type='text'>
Pull v4.4 EFI updates from Matt Fleming:

  - Make the EFI System Resource Table (ESRT) driver explicitly
    non-modular by ripping out the module_* code since Kconfig doesn't
    allow it to be built as a module anyway. (Paul Gortmaker)

  - Make the x86 efi=debug kernel parameter, which enables EFI debug
    code and output, generic and usable by arm64. (Leif Lindholm)

  - Add support to the x86 EFI boot stub for 64-bit Graphics Output
    Protocol frame buffer addresses. (Matt Fleming)

  - Detect when the UEFI v2.5 EFI_PROPERTIES_TABLE feature is enabled
    in the firmware and set an efi.flags bit so the kernel knows when
    it can apply more strict runtime mapping attributes - Ard Biesheuvel

  - Auto-load the efi-pstore module on EFI systems, just like we
    currently do for the efivars module. (Ben Hutchings)

  - Add "efi_fake_mem" kernel parameter which allows the system's EFI
    memory map to be updated with additional attributes for specific
    memory ranges. This is useful for testing the kernel code that handles
    the EFI_MEMORY_MORE_RELIABLE memmap bit even if your firmware
    doesn't include support. (Taku Izumi)

Note: there is a semantic conflict between the following two commits:

  8a53554e12e9 ("x86/efi: Fix multiple GOP device support")
  ae2ee627dc87 ("efifb: Add support for 64-bit frame buffer addresses")

I fixed up the interaction in the merge commit, changing the type of
current_fb_base from u32 to u64.

Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
</content>
</entry>
<entry>
<title>efi: Add "efi_fake_mem" boot option</title>
<updated>2015-10-12T13:20:09Z</updated>
<author>
<name>Taku Izumi</name>
</author>
<published>2015-09-30T14:01:56Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=0f96a99dab366333439e110d6ad253bc7c557c09'/>
<id>urn:sha1:0f96a99dab366333439e110d6ad253bc7c557c09</id>
<content type='text'>
This patch introduces new boot option named "efi_fake_mem".
By specifying this parameter, you can add arbitrary attribute
to specific memory range.
This is useful for debugging of Address Range Mirroring feature.

For example, if "efi_fake_mem=2G@4G:0x10000,2G@0x10a0000000:0x10000"
is specified, the original (firmware provided) EFI memmap will be
updated so that the specified memory regions have
EFI_MEMORY_MORE_RELIABLE attribute (0x10000):

 &lt;original&gt;
   efi: mem36: [Conventional Memory|  |  |  |  |  |   |WB|WT|WC|UC] range=[0x0000000100000000-0x00000020a0000000) (129536MB)

 &lt;updated&gt;
   efi: mem36: [Conventional Memory|  |MR|  |  |  |   |WB|WT|WC|UC] range=[0x0000000100000000-0x0000000180000000) (2048MB)
   efi: mem37: [Conventional Memory|  |  |  |  |  |   |WB|WT|WC|UC] range=[0x0000000180000000-0x00000010a0000000) (61952MB)
   efi: mem38: [Conventional Memory|  |MR|  |  |  |   |WB|WT|WC|UC] range=[0x00000010a0000000-0x0000001120000000) (2048MB)
   efi: mem39: [Conventional Memory|  |  |  |  |  |   |WB|WT|WC|UC] range=[0x0000001120000000-0x00000020a0000000) (63488MB)

And you will find that the following message is output:

   efi: Memory: 4096M/131455M mirrored memory

Signed-off-by: Taku Izumi &lt;izumi.taku@jp.fujitsu.com&gt;
Cc: Tony Luck &lt;tony.luck@intel.com&gt;
Cc: Xishi Qiu &lt;qiuxishi@huawei.com&gt;
Cc: Kamezawa Hiroyuki &lt;kamezawa.hiroyu@jp.fujitsu.com&gt;
Cc: Ard Biesheuvel &lt;ard.biesheuvel@linaro.org&gt;
Signed-off-by: Matt Fleming &lt;matt.fleming@intel.com&gt;
</content>
</entry>
<entry>
<title>kexec: split kexec_load syscall from kexec core code</title>
<updated>2015-09-10T20:29:01Z</updated>
<author>
<name>Dave Young</name>
</author>
<published>2015-09-09T22:38:55Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=2965faa5e03d1e71e9ff9aa143fff39e0a77543a'/>
<id>urn:sha1:2965faa5e03d1e71e9ff9aa143fff39e0a77543a</id>
<content type='text'>
There are two kexec load syscalls, kexec_load another and kexec_file_load.
 kexec_file_load has been splited as kernel/kexec_file.c.  In this patch I
split kexec_load syscall code to kernel/kexec.c.

And add a new kconfig option KEXEC_CORE, so we can disable kexec_load and
use kexec_file_load only, or vice verse.

The original requirement is from Ted Ts'o, he want kexec kernel signature
being checked with CONFIG_KEXEC_VERIFY_SIG enabled.  But kexec-tools use
kexec_load syscall can bypass the checking.

Vivek Goyal proposed to create a common kconfig option so user can compile
in only one syscall for loading kexec kernel.  KEXEC/KEXEC_FILE selects
KEXEC_CORE so that old config files still work.

Because there's general code need CONFIG_KEXEC_CORE, so I updated all the
architecture Kconfig with a new option KEXEC_CORE, and let KEXEC selects
KEXEC_CORE in arch Kconfig.  Also updated general kernel code with to
kexec_load syscall.

[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Dave Young &lt;dyoung@redhat.com&gt;
Cc: Eric W. Biederman &lt;ebiederm@xmission.com&gt;
Cc: Vivek Goyal &lt;vgoyal@redhat.com&gt;
Cc: Petr Tesarik &lt;ptesarik@suse.cz&gt;
Cc: Theodore Ts'o &lt;tytso@mit.edu&gt;
Cc: Josh Boyer &lt;jwboyer@fedoraproject.org&gt;
Cc: David Howells &lt;dhowells@redhat.com&gt;
Cc: Geert Uytterhoeven &lt;geert@linux-m68k.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>efi: Work around ia64 build problem with ESRT driver</title>
<updated>2015-06-08T09:51:31Z</updated>
<author>
<name>Peter Jones</name>
</author>
<published>2015-06-05T19:14:54Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=3846c15820a1841225d0245afda4875af23dfbbe'/>
<id>urn:sha1:3846c15820a1841225d0245afda4875af23dfbbe</id>
<content type='text'>
So, I'm told this problem exists in the world:

 &gt; Subject: Build error in -next due to 'efi: Add esrt support'
 &gt;
 &gt; Building ia64:defconfig ... failed
 &gt; --------------
 &gt; Error log:
 &gt;
 &gt; drivers/firmware/efi/esrt.c:28:31: fatal error: asm/early_ioremap.h: No such file or directory
 &gt;

I'm not really sure how it's okay that we have things in asm-generic on
some platforms but not others - is having it the same everywhere not the
whole point of asm-generic?

That said, ia64 doesn't have early_ioremap.h .  So instead, since it's
difficult to imagine new IA64 machines with UEFI 2.5, just don't build
this code there.

To me this looks like a workaround - doing something like:

generic-y += early_ioremap.h

in arch/ia64/include/asm/Kbuild would appear to be more correct, but
ia64 has its own early_memremap() decl in arch/ia64/include/asm/io.h ,
and it's a macro.  So adding the above /and/ requiring that asm/io.h be
included /after/ asm/early_ioremap.h in all cases would fix it, but
that's pretty ugly as well.  Since I'm not going to spend the rest of my
life rectifying ia64 headers vs "generic" headers that aren't generic,
it's much simpler to just not build there.

Note that I've only actually tried to build this patch on x86_64, but
esrt.o still gets built there, and that would seem to demonstrate that
the conditional building is working correctly at all the places the code
built before.  I no longer have any ia64 machines handy to test that the
exclusion actually works there.

Signed-off-by: Peter Jones &lt;pjones@redhat.com&gt;
Acked-by: Tony Luck &lt;tony.luck@intel.com&gt;
Reviewed-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
(Compile-)Tested-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Signed-off-by: Matt Fleming &lt;matt.fleming@intel.com&gt;
</content>
</entry>
<entry>
<title>efi: Update the URLs for efibootmgr</title>
<updated>2015-01-08T03:06:28Z</updated>
<author>
<name>Peter Jones</name>
</author>
<published>2014-12-09T21:14:11Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=0e4ca02b3fc0e33e96eef1f4da227eab2c67b8ac'/>
<id>urn:sha1:0e4ca02b3fc0e33e96eef1f4da227eab2c67b8ac</id>
<content type='text'>
Matt Domsch changed the dell page to point to the new upstream quite
some time ago; kernel should reflect that here as well.

Cc: Matt Domsch &lt;Matt_Domsch@dell.com&gt;
Signed-off-by: Peter Jones &lt;pjones@redhat.com&gt;
Signed-off-by: Ricardo Neri &lt;ricardo.neri-calderon@linux.intel.com&gt;
</content>
</entry>
<entry>
<title>efi: efistub: Convert into static library</title>
<updated>2014-07-18T20:22:19Z</updated>
<author>
<name>Ard Biesheuvel</name>
</author>
<published>2014-07-02T12:54:43Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=f4f75ad5741fe0331bbe1f5c42b906cda299f26b'/>
<id>urn:sha1:f4f75ad5741fe0331bbe1f5c42b906cda299f26b</id>
<content type='text'>
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 &lt;ard.biesheuvel@linaro.org&gt;
Signed-off-by: Matt Fleming &lt;matt.fleming@intel.com&gt;
</content>
</entry>
</feed>
