<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="/rss.xsl.xml"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
    <title>Changes in Makefile</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>c44b6be6 - efi: Add tee-based EFI variable driver</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/firmware/efi/Makefile#c44b6be6</link>
        <description>efi: Add tee-based EFI variable driverWhen the flash is not owned by the non-secure world, accessing the EFIvariables is straight-forward and done via EFI Runtime VariableServices.  In this case, critical variables for system integrity andsecurity are normally stored in the dedicated secure storage and canonly be manipulated directly from the secure world.Usually, small embedded devices don&apos;t have the special dedicated securestorage. The eMMC device with an RPMB partition is becoming more common,and we can use this RPMB partition to store the EFI Variables.The eMMC device is typically owned by the non-secure world (Linux in ourcase). There is an existing solution utilizing eMMC RPMB partition forEFI Variables, it is implemented by interacting with TEE (OP-TEE in thiscase), StandaloneMM (as EFI Variable Service Pseudo TA), eMMC driver andtee-supplicant. The last piece is the tee-based variable access driverto interact with TEE and StandaloneMM.So let&apos;s add the kernel functions needed.This feature is implemented as a kernel module.  StMM PTA hasTA_FLAG_DEVICE_ENUM_SUPP flag when registered to OP-TEE so that thistee_stmm_efi module is probed after tee-supplicant starts, since&quot;SetVariable&quot; EFI Runtime Variable Service requires to interact withtee-supplicant.Acked-by: Sumit Garg &lt;sumit.garg@linaro.org&gt;Co-developed-by: Ilias Apalodimas &lt;ilias.apalodimas@linaro.org&gt;Signed-off-by: Ilias Apalodimas &lt;ilias.apalodimas@linaro.org&gt;Signed-off-by: Masahisa Kojima &lt;masahisa.kojima@linaro.org&gt;Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;

            List of files:
            /linux-6.15/drivers/firmware/efi/Makefile</description>
        <pubDate>Tue, 07 Nov 2023 05:40:54 +0000</pubDate>
        <dc:creator>Masahisa Kojima &lt;masahisa.kojima@linaro.org&gt;</dc:creator>
    </item>
<item>
        <title>2053bc57 - efi: Add unaccepted memory support</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/firmware/efi/Makefile#2053bc57</link>
        <description>efi: Add unaccepted memory supportefi_config_parse_tables() reserves memory that holds unaccepted memoryconfiguration table so it won&apos;t be reused by page allocator.Core-mm requires few helpers to support unaccepted memory: - accept_memory() checks the range of addresses against the bitmap and   accept memory if needed. - range_contains_unaccepted_memory() checks if anything within the   range requires acceptance.Architectural code has to provide efi_get_unaccepted_table() thatreturns pointer to the unaccepted memory configuration table.arch_accept_memory() handles arch-specific part of memory acceptance.Signed-off-by: Kirill A. Shutemov &lt;kirill.shutemov@linux.intel.com&gt;Signed-off-by: Borislav Petkov (AMD) &lt;bp@alien8.de&gt;Reviewed-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;Reviewed-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;Link: https://lore.kernel.org/r/20230606142637.5171-6-kirill.shutemov@linux.intel.com

            List of files:
            /linux-6.15/drivers/firmware/efi/Makefile</description>
        <pubDate>Tue, 06 Jun 2023 14:26:33 +0000</pubDate>
        <dc:creator>Kirill A. Shutemov &lt;kirill.shutemov@linux.intel.com&gt;</dc:creator>
    </item>
<item>
        <title>abdbf1a2 - efi/cper, cxl: Decode CXL Protocol Error Section</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/firmware/efi/Makefile#abdbf1a2</link>
        <description>efi/cper, cxl: Decode CXL Protocol Error SectionAdd support for decoding CXL Protocol Error Section as defined in UEFI 2.10Section N.2.13.Do the section decoding in a new cper_cxl.c file. This new file will beused in the future for more CXL CPERs decode support. Add this to theexisting UEFI_CPER config.Signed-off-by: Smita Koralahalli &lt;Smita.KoralahalliChannabasappa@amd.com&gt;Reviewed-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;

            List of files:
            /linux-6.15/drivers/firmware/efi/Makefile</description>
        <pubDate>Fri, 28 Oct 2022 20:09:49 +0000</pubDate>
        <dc:creator>Smita Koralahalli &lt;Smita.KoralahalliChannabasappa@amd.com&gt;</dc:creator>
    </item>
<item>
        <title>1fff234d - efi: x86: Move EFI runtime map sysfs code to arch/x86</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/firmware/efi/Makefile#1fff234d</link>
        <description>efi: x86: Move EFI runtime map sysfs code to arch/x86The EFI runtime map code is only wired up on x86, which is the onlyarchitecture that has a need for it in its implementation of kexec.So let&apos;s move this code under arch/x86 and drop all references to itfrom generic code. To ensure that the efi_runtime_map_init() is invokedat the appropriate time use a &apos;sync&apos; subsys_initcall() that will becalled right after the EFI initcall made from generic code where theoriginal invocation of efi_runtime_map_init() resided.Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;Reviewed-by: Dave Young &lt;dyoung@redhat.com&gt;

            List of files:
            /linux-6.15/drivers/firmware/efi/Makefile</description>
        <pubDate>Mon, 07 Nov 2022 08:17:16 +0000</pubDate>
        <dc:creator>Ard Biesheuvel &lt;ardb@kernel.org&gt;</dc:creator>
    </item>
<item>
        <title>4059ba65 - efi: memmap: Move EFI fake memmap support into x86 arch tree</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/firmware/efi/Makefile#4059ba65</link>
        <description>efi: memmap: Move EFI fake memmap support into x86 arch treeThe EFI fake memmap support is specific to x86, which manipulates theEFI memory map in various different ways after receiving it from the EFIstub. On other architectures, we have managed to push back on this, andthe EFI memory map is kept pristine.So let&apos;s move the fake memmap code into the x86 arch tree, where itarguably belongs.Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;

            List of files:
            /linux-6.15/drivers/firmware/efi/Makefile</description>
        <pubDate>Sat, 01 Oct 2022 16:38:15 +0000</pubDate>
        <dc:creator>Ard Biesheuvel &lt;ardb@kernel.org&gt;</dc:creator>
    </item>
<item>
        <title>0f5b2c69 - efi: vars: Remove deprecated &apos;efivars&apos; sysfs interface</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/firmware/efi/Makefile#0f5b2c69</link>
        <description>efi: vars: Remove deprecated &apos;efivars&apos; sysfs interfaceCommit 5d9db883761a (&quot;efi: Add support for a UEFI variable filesystem&quot;)dated Oct 5, 2012, introduced a new efivarfs pseudo-filesystem toreplace the efivars sysfs interface that was used up to that point toexpose EFI variables to user space.The main problem with the sysfs interface was that it only supported upto 1024 bytes of payload per file, whereas the underlying variablesthemselves are only bounded by a platform specific per-variable andglobal limit that is typically much higher than 1024 bytes.The deprecated sysfs interface is only enabled on x86 and Itanium, otherEFI enabled architectures only support the efivarfs pseudo-filesystem.So let&apos;s finally rip off the band aid, and drop the old interfaceentirely. This will make it easier to refactor and clean up theunderlying infrastructure that is shared between efivars, efivarfs andefi-pstore, and is long overdue for a makeover.Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;

            List of files:
            /linux-6.15/drivers/firmware/efi/Makefile</description>
        <pubDate>Mon, 20 Jun 2022 11:34:03 +0000</pubDate>
        <dc:creator>Ard Biesheuvel &lt;ardb@kernel.org&gt;</dc:creator>
    </item>
<item>
        <title>d391c582 - drivers/firmware: move x86 Generic System Framebuffers support</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/firmware/efi/Makefile#d391c582</link>
        <description>drivers/firmware: move x86 Generic System Framebuffers supportThe x86 architecture has generic support to register a system framebufferplatform device. It either registers a &quot;simple-framebuffer&quot; if the configoption CONFIG_X86_SYSFB is enabled, or a legacy VGA/VBE/EFI FB device.But the code is generic enough to be reused by other architectures and canbe moved out of the arch/x86 directory.This will allow to also support the simple{fb,drm} drivers on non-x86 EFIplatforms, such as aarch64 where these drivers are only supported with DT.Signed-off-by: Javier Martinez Canillas &lt;javierm@redhat.com&gt;Acked-by: Borislav Petkov &lt;bp@suse.de&gt;Acked-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;Acked-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;Signed-off-by: Thomas Zimmermann &lt;tzimmermann@suse.de&gt;Link: https://patchwork.freedesktop.org/patch/msgid/20210625130947.1803678-2-javierm@redhat.com

            List of files:
            /linux-6.15/drivers/firmware/efi/Makefile</description>
        <pubDate>Fri, 25 Jun 2021 13:09:46 +0000</pubDate>
        <dc:creator>Javier Martinez Canillas &lt;javierm@redhat.com&gt;</dc:creator>
    </item>
<item>
        <title>e0a6aa30 - efi: ia64: disable the capsule loader</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/firmware/efi/Makefile#e0a6aa30</link>
        <description>efi: ia64: disable the capsule loaderEFI capsule loading is a feature that was introduced into EFI long afterits initial introduction on Itanium, and it is highly unlikely that IA64systems are receiving firmware updates in the first place, let aloneusing EFI capsules.So let&apos;s disable capsule support altogether on IA64. This fixes a builderror on IA64 due to a recent change that added an unconditionalinclude of asm/efi.h, which IA64 does not provide.While at it, tweak the make rules a bit so that the EFI capsulecomponent that is always builtin (even if the EFI capsule loader itselfis built as a module) is omitted for all architectures if the module isnot enabled in the build.Cc: Tony Luck &lt;tony.luck@intel.com&gt;Link: https://lore.kernel.org/linux-efi/20201214152200.38353-1-ardb@kernel.orgSigned-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;

            List of files:
            /linux-6.15/drivers/firmware/efi/Makefile</description>
        <pubDate>Sun, 13 Dec 2020 08:39:40 +0000</pubDate>
        <dc:creator>Ard Biesheuvel &lt;ardb@kernel.org&gt;</dc:creator>
    </item>
<item>
        <title>b91540d5 - RISC-V: Add EFI runtime services</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/firmware/efi/Makefile#b91540d5</link>
        <description>RISC-V: Add EFI runtime servicesThis patch adds EFI runtime service support for RISC-V.Signed-off-by: Atish Patra &lt;atish.patra@wdc.com&gt;[ardb: - Remove the page check]Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;Acked-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;Signed-off-by: Palmer Dabbelt &lt;palmerdabbelt@google.com&gt;

            List of files:
            /linux-6.15/drivers/firmware/efi/Makefile</description>
        <pubDate>Thu, 17 Sep 2020 22:37:15 +0000</pubDate>
        <dc:creator>Atish Patra &lt;atish.patra@wdc.com&gt;</dc:creator>
    </item>
<item>
        <title>58c90902 - efi: Support for MOK variable config table</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/firmware/efi/Makefile#58c90902</link>
        <description>efi: Support for MOK variable config tableBecause of system-specific EFI firmware limitations, EFI volatilevariables may not be capable of holding the required contents ofthe Machine Owner Key (MOK) certificate store when the certificatelist grows above some size. Therefore, an EFI boot loader may passthe MOK certs via a EFI configuration table created specifically forthis purpose to avoid this firmware limitation.An EFI configuration table is a much more primitive mechanismcompared to EFI variables and is well suited for one-way passageof static information from a pre-OS environment to the kernel.This patch adds initial kernel support to recognize, parse,and validate the EFI MOK configuration table, where namedentries contain the same data that would otherwise be providedin similarly named EFI variables.Additionally, this patch creates a sysfs binary file for eachEFI MOK configuration table entry found. These files are read-onlyto root and are provided for use by user space utilities such asmokutil.A subsequent patch will load MOK certs into the trusted platformkey ring using this infrastructure.Signed-off-by: Lenny Szubowicz &lt;lszubowi@redhat.com&gt;Link: https://lore.kernel.org/r/20200905013107.10457-2-lszubowi@redhat.comSigned-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;

            List of files:
            /linux-6.15/drivers/firmware/efi/Makefile</description>
        <pubDate>Sat, 05 Sep 2020 01:31:05 +0000</pubDate>
        <dc:creator>Lenny Szubowicz &lt;lszubowi@redhat.com&gt;</dc:creator>
    </item>
<item>
        <title>f30f242f - efi: Rename arm-init to efi-init common for all arch</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/firmware/efi/Makefile#f30f242f</link>
        <description>efi: Rename arm-init to efi-init common for all archarm-init is responsible for setting up efi runtime and doesn&apos;t actuallydo any ARM specific stuff. RISC-V can use the same source code as it is.Rename it to efi-init so that RISC-V can use it.Signed-off-by: Atish Patra &lt;atish.patra@wdc.com&gt;Link: https://lore.kernel.org/r/20200819222425.30721-8-atish.patra@wdc.comSigned-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;

            List of files:
            /linux-6.15/drivers/firmware/efi/Makefile</description>
        <pubDate>Wed, 19 Aug 2020 22:24:23 +0000</pubDate>
        <dc:creator>Atish Patra &lt;atish.patra@wdc.com&gt;</dc:creator>
    </item>
<item>
        <title>2fb2c179 - efi/libstub: Avoid linking libstub/lib-ksyms.o into vmlinux</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/firmware/efi/Makefile#2fb2c179</link>
        <description>efi/libstub: Avoid linking libstub/lib-ksyms.o into vmlinuxdrivers/firmware/efi/libstub/Makefile builds a static library, whichis not linked into the main vmlinux target in the ordinary way [arm64],or at all [ARM, x86].Since commit:  7f2084fa55e6 (&quot;[kbuild] handle exports in lib-y objects reliably&quot;)any Makefile using lib-y generates lib-ksyms.o which is linked into vmlinux.In this case, the following garbage object is linked into vmlinux.  drivers/firmware/efi/libstub/lib-ksyms.oWe do not want to follow the default linking rules for static librariesbuilt under libstub/ so using subdir-y instead of obj-y is the correctway to descend into this directory.Signed-off-by: Masahiro Yamada &lt;masahiroy@kernel.org&gt;Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;[ardb: update commit log to clarify that arm64 deviates in this respect]Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;Link: https://lore.kernel.org/r/20200305055047.6097-1-masahiroy@kernel.orgLink: https://lore.kernel.org/r/20200308080859.21568-23-ardb@kernel.org

            List of files:
            /linux-6.15/drivers/firmware/efi/Makefile</description>
        <pubDate>Sun, 08 Mar 2020 08:08:53 +0000</pubDate>
        <dc:creator>Masahiro Yamada &lt;masahiroy@kernel.org&gt;</dc:creator>
    </item>
<item>
        <title>f0df68d5 - efi: Add embedded peripheral firmware support</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/firmware/efi/Makefile#f0df68d5</link>
        <description>efi: Add embedded peripheral firmware supportJust like with PCI options ROMs, which we save in the setup_efi_pci*functions from arch/x86/boot/compressed/eboot.c, the EFI code / ROM itselfsometimes may contain data which is useful/necessary for peripheral driversto have access to.Specifically the EFI code may contain an embedded copy of firmware whichneeds to be (re)loaded into the peripheral. Normally such firmware would bepart of linux-firmware, but in some cases this is not feasible, for 2reasons:1) The firmware is customized for a specific use-case of the chipset / usewith a specific hardware model, so we cannot have a single firmware filefor the chipset. E.g. touchscreen controller firmwares are compiledspecifically for the hardware model they are used with, as they arecalibrated for a specific model digitizer.2) Despite repeated attempts we have failed to get permission toredistribute the firmware. This is especially a problem with customizedfirmwares, these get created by the chip vendor for a specific ODM and thecopyright may partially belong with the ODM, so the chip vendor cannotgive a blanket permission to distribute these.This commit adds support for finding peripheral firmware embedded in theEFI code and makes the found firmware available through the newefi_get_embedded_fw() function.Support for loading these firmwares through the standard firmware loadingmechanism is added in a follow-up commit in this patch-series.Note we check the EFI_BOOT_SERVICES_CODE for embedded firmware near the endof start_kernel(), just before calling rest_init(), this is on purposebecause the typical EFI_BOOT_SERVICES_CODE memory-segment is too large forearly_memremap(), so the check must be done after mm_init(). This relieson EFI_BOOT_SERVICES_CODE not being free-ed until efi_free_boot_services()is called, which means that this will only work on x86 for now.Reported-by: Dave Olsthoorn &lt;dave@bewaar.me&gt;Suggested-by: Peter Jones &lt;pjones@redhat.com&gt;Acked-by: Ard Biesheuvel &lt;ard.biesheuvel@linaro.org&gt;Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;Link: https://lore.kernel.org/r/20200115163554.101315-3-hdegoede@redhat.comSigned-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;

            List of files:
            /linux-6.15/drivers/firmware/efi/Makefile</description>
        <pubDate>Wed, 15 Jan 2020 16:35:46 +0000</pubDate>
        <dc:creator>Hans de Goede &lt;hdegoede@redhat.com&gt;</dc:creator>
    </item>
<item>
        <title>ac5abc70 - efi/arm: Move FDT param discovery code out of efi.c</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/firmware/efi/Makefile#ac5abc70</link>
        <description>efi/arm: Move FDT param discovery code out of efi.cOn ARM systems, we discover the UEFI system table address and memorymap address from the /chosen node in the device tree, or in the Xencase, from a similar node under /hypervisor.Before making some functional changes to that code, move it into itsown file that only gets built if CONFIG_EFI_PARAMS_FROM_FDT=y.Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;

            List of files:
            /linux-6.15/drivers/firmware/efi/Makefile</description>
        <pubDate>Tue, 18 Feb 2020 08:54:05 +0000</pubDate>
        <dc:creator>Ard Biesheuvel &lt;ardb@kernel.org&gt;</dc:creator>
    </item>
<item>
        <title>199c8471 - x86/efi: Add efi_fake_mem support for EFI_MEMORY_SP</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/firmware/efi/Makefile#199c8471</link>
        <description>x86/efi: Add efi_fake_mem support for EFI_MEMORY_SPGiven that EFI_MEMORY_SP is platform BIOS policy decision for markingmemory ranges as &quot;reserved for a specific purpose&quot; there will inevitablybe scenarios where the BIOS omits the attribute in situations where itis desired. Unlike other attributes if the OS wants to reserve thismemory from the kernel the reservation needs to happen early in init. Soearly, in fact, that it needs to happen before e820__memblock_setup()which is a pre-requisite for efi_fake_memmap() that wants to allocatememory for the updated table.Introduce an x86 specific efi_fake_memmap_early() that can search forattempts to set EFI_MEMORY_SP via efi_fake_mem and update the e820 tableaccordingly.The KASLR code that scans the command line looking for user-directedmemory reservations also needs to be updated to consider&quot;efi_fake_mem=nn@ss:0x40000&quot; requests.Acked-by: Ard Biesheuvel &lt;ard.biesheuvel@linaro.org&gt;Reviewed-by: Dave Hansen &lt;dave.hansen@linux.intel.com&gt;Signed-off-by: Dan Williams &lt;dan.j.williams@intel.com&gt;Acked-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;

            List of files:
            /linux-6.15/drivers/firmware/efi/Makefile</description>
        <pubDate>Thu, 07 Nov 2019 01:43:26 +0000</pubDate>
        <dc:creator>Dan Williams &lt;dan.j.williams@intel.com&gt;</dc:creator>
    </item>
<item>
        <title>1c5fecb6 - efi: Export Runtime Configuration Interface table to sysfs</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/firmware/efi/Makefile#1c5fecb6</link>
        <description>efi: Export Runtime Configuration Interface table to sysfsSystem firmware advertises the address of the &apos;RuntimeConfiguration Interface table version 2 (RCI2)&apos; viaan EFI Configuration Table entry. This code retrieves the RCI2table from the address and exports it to sysfs as a binaryattribute &apos;rci2&apos; under /sys/firmware/efi/tables directory.The approach adopted is similar to the attribute &apos;DMI&apos; under/sys/firmware/dmi/tables.RCI2 table contains BIOS HII in XML format and is used to populateBIOS setup page in Dell EMC OpenManage Server Administrator tool.The BIOS setup page contains BIOS tokens which can be configured.Signed-off-by: Narendra K &lt;Narendra.K@dell.com&gt;Reviewed-by: Mario Limonciello &lt;mario.limonciello@dell.com&gt;Signed-off-by: Ard Biesheuvel &lt;ard.biesheuvel@linaro.org&gt;

            List of files:
            /linux-6.15/drivers/firmware/efi/Makefile</description>
        <pubDate>Wed, 10 Jul 2019 18:59:15 +0000</pubDate>
        <dc:creator>Narendra K &lt;Narendra.K@dell.com&gt;</dc:creator>
    </item>
<item>
        <title>69c1f396 - efi/x86: Convert x86 EFI earlyprintk into generic earlycon implementation</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/firmware/efi/Makefile#69c1f396</link>
        <description>efi/x86: Convert x86 EFI earlyprintk into generic earlycon implementationMove the x86 EFI earlyprintk implementation to a shared location underdrivers/firmware and tweak it slightly so we can expose it as an earlyconimplementation (which is generic) rather than earlyprintk (which is onlyimplemented for a few architectures)This also involves switching to write-combine mappings by default (whichis required on ARM since device mappings lack memory semantics, and somemcpy/memset may not be used on them), and adding support for sharedmemory framebuffers on cache coherent non-x86 systems (which do nottolerate mismatched attributes).Note that 32-bit ARM does not populate its struct screen_info earlyenough for earlycon=efifb to work, so it is disabled there.Signed-off-by: Ard Biesheuvel &lt;ard.biesheuvel@linaro.org&gt;Reviewed-by: Alexander Graf &lt;agraf@suse.de&gt;Cc: AKASHI Takahiro &lt;takahiro.akashi@linaro.org&gt;Cc: Bjorn Andersson &lt;bjorn.andersson@linaro.org&gt;Cc: Borislav Petkov &lt;bp@alien8.de&gt;Cc: Heinrich Schuchardt &lt;xypron.glpk@gmx.de&gt;Cc: Jeffrey Hugo &lt;jhugo@codeaurora.org&gt;Cc: Lee Jones &lt;lee.jones@linaro.org&gt;Cc: Leif Lindholm &lt;leif.lindholm@linaro.org&gt;Cc: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;Cc: Matt Fleming &lt;matt@codeblueprint.co.uk&gt;Cc: Peter Jones &lt;pjones@redhat.com&gt;Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;Cc: Sai Praneeth Prakhya &lt;sai.praneeth.prakhya@intel.com&gt;Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;Cc: linux-efi@vger.kernel.orgLink: http://lkml.kernel.org/r/20190202094119.13230-10-ard.biesheuvel@linaro.orgSigned-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;

            List of files:
            /linux-6.15/drivers/firmware/efi/Makefile</description>
        <pubDate>Sat, 02 Feb 2019 09:41:18 +0000</pubDate>
        <dc:creator>Ard Biesheuvel &lt;ard.biesheuvel@linaro.org&gt;</dc:creator>
    </item>
<item>
        <title>f9e1bdb9 - efi: Decode IA32/X64 Processor Error Section</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/firmware/efi/Makefile#f9e1bdb9</link>
        <description>efi: Decode IA32/X64 Processor Error SectionRecognize the IA32/X64 Processor Error Section.Do the section decoding in a new &quot;cper-x86.c&quot; file and add this to theMakefile depending on a new &quot;UEFI_CPER_X86&quot; config option.Print the Local APIC ID and CPUID info from the Processor Error Record.The &quot;Processor Error Info&quot; and &quot;Processor Context&quot; fields will bedecoded in following patches.Based on UEFI 2.7 Table 252. Processor Error Record.Signed-off-by: Yazen Ghannam &lt;yazen.ghannam@amd.com&gt;Signed-off-by: Ard Biesheuvel &lt;ard.biesheuvel@linaro.org&gt;Cc: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;Cc: Matt Fleming &lt;matt@codeblueprint.co.uk&gt;Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;Cc: linux-efi@vger.kernel.orgLink: http://lkml.kernel.org/r/20180504060003.19618-5-ard.biesheuvel@linaro.orgSigned-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;

            List of files:
            /linux-6.15/drivers/firmware/efi/Makefile</description>
        <pubDate>Fri, 04 May 2018 05:59:50 +0000</pubDate>
        <dc:creator>Yazen Ghannam &lt;yazen.ghannam@amd.com&gt;</dc:creator>
    </item>
<item>
        <title>33b6d034 - efi: call get_event_log before ExitBootServices</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/firmware/efi/Makefile#33b6d034</link>
        <description>efi: call get_event_log before ExitBootServicesWith TPM 2.0 specification, the event logs may only be accessible bycalling an EFI Boot Service. Modify the EFI stub to copy the log area toa new Linux-specific EFI configuration table so it remains accessibleonce booted.When calling this service, it is possible to specify the expected formatof the logs: TPM 1.2 (SHA1) or TPM 2.0 (&quot;Crypto Agile&quot;). For now, only thefirst format is retrieved.Signed-off-by: Thiebaud Weksteen &lt;tweek@google.com&gt;Reviewed-by: Javier Martinez Canillas &lt;javierm@redhat.com&gt;Tested-by: Javier Martinez Canillas &lt;javierm@redhat.com&gt;Tested-by: Jarkko Sakkinen  &lt;jarkko.sakkinen@linux.intel.com&gt;Reviewed-by: Jarkko Sakkinen  &lt;jarkko.sakkinen@linux.intel.com&gt;Signed-off-by: Jarkko Sakkinen  &lt;jarkko.sakkinen@linux.intel.com&gt;

            List of files:
            /linux-6.15/drivers/firmware/efi/Makefile</description>
        <pubDate>Wed, 20 Sep 2017 08:13:39 +0000</pubDate>
        <dc:creator>Thiebaud Weksteen &lt;tweek@google.com&gt;</dc:creator>
    </item>
<item>
        <title>c6d8c8ef - efi: Move ARM CPER code to new file</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/firmware/efi/Makefile#c6d8c8ef</link>
        <description>efi: Move ARM CPER code to new fileThe ARM CPER code is currently mixed in with the other CPER code. Move itto a new file to separate it from the rest of the CPER code.Signed-off-by: Tyler Baicar &lt;tbaicar@codeaurora.org&gt;Signed-off-by: Ard Biesheuvel &lt;ard.biesheuvel@linaro.org&gt;Cc: Arvind Yadav &lt;arvind.yadav.cs@gmail.com&gt;Cc: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;Cc: Matt Fleming &lt;matt@codeblueprint.co.uk&gt;Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;Cc: Stephen Boyd &lt;sboyd@codeaurora.org&gt;Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;Cc: Vasyl Gomonovych &lt;gomonovych@gmail.com&gt;Cc: linux-efi@vger.kernel.orgLink: http://lkml.kernel.org/r/20180102181042.19074-5-ard.biesheuvel@linaro.orgSigned-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;

            List of files:
            /linux-6.15/drivers/firmware/efi/Makefile</description>
        <pubDate>Tue, 02 Jan 2018 18:10:41 +0000</pubDate>
        <dc:creator>Tyler Baicar &lt;tbaicar@codeaurora.org&gt;</dc:creator>
    </item>
</channel>
</rss>
