Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 27 9月, 2022 3 次提交
    • A
      efi: libstub: remove pointless goto kludge · a12b78b5
      由 Ard Biesheuvel 提交于 
      Remove some goto cruft that serves no purpose and obfuscates the code.
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
      a12b78b5
    • A
      efi: libstub: simplify efi_get_memory_map() and struct efi_boot_memmap · eab31265
      由 Ard Biesheuvel 提交于 
      Currently, struct efi_boot_memmap is a struct that is passed around
between callers of efi_get_memory_map() and the users of the resulting
data, and which carries pointers to various variables whose values are
provided by the EFI GetMemoryMap() boot service.

This is overly complex, and it is much easier to carry these values in
the struct itself. So turn the struct into one that carries these data
items directly, including a flex array for the variable number of EFI
memory descriptors that the boot service may return.
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
      eab31265
    • A
      efi: libstub: avoid efi_get_memory_map() for allocating the virt map · f80d2604
      由 Ard Biesheuvel 提交于 
      The virt map is a set of efi_memory_desc_t descriptors that are passed
to SetVirtualAddressMap() to inform the firmware about the desired
virtual mapping of the regions marked as EFI_MEMORY_RUNTIME. The only
reason we currently call the efi_get_memory_map() helper is that it
gives us an allocation that is guaranteed to be of sufficient size.
However, efi_get_memory_map() has grown some additional complexity over
the years, and today, we're actually better off calling the EFI boot
service directly with a zero size, which tells us how much memory should
be enough for the virt map.

While at it, avoid creating the VA map allocation if we will not be
using it anyway, i.e., if efi_novamap is true.
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
      f80d2604
  3. 21 9月, 2022 1 次提交
  5. 06 9月, 2022 1 次提交
    • H
      efi/loongarch: Add efistub booting support · ead384d9
      由 Huacai Chen 提交于 
      This patch adds efistub booting support, which is the standard UEFI boot
protocol for LoongArch to use.

We use generic efistub, which means we can pass boot information (i.e.,
system table, memory map, kernel command line, initrd) via a light FDT
and drop a lot of non-standard code.

We use a flat mapping to map the efi runtime in the kernel's address
space. In efi, VA = PA; in kernel, VA = PA + PAGE_OFFSET. As a result,
flat mapping is not identity mapping, SetVirtualAddressMap() is still
needed for the efi runtime.
Tested-by: NXi Ruoyao <xry111@xry111.site>
Signed-off-by: NHuacai Chen <chenhuacai@loongson.cn>
[ardb: change fpic to fpie as suggested by Xi Ruoyao]
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
      ead384d9
  7. 22 7月, 2022 2 次提交
  9. 20 7月, 2022 1 次提交
  11. 16 7月, 2022 1 次提交
  13. 14 7月, 2022 6 次提交
  15. 10 7月, 2022 2 次提交
    • H
      efi: Fix efi_power_off() not being run before acpi_power_off() when necessary · d40908f2
      由 Hans de Goede 提交于 
      Commit 98f30d0e ("ACPI: power: Switch to sys-off handler API")
switched the ACPI sleep code from directly setting the old global
pm_power_off handler to using the new register_sys_off_handler()
mechanism with a priority of SYS_OFF_PRIO_FIRMWARE.

This is a problem when the old global pm_power_off handler would later
be overwritten, such as done by the late_initcall(efi_shutdown_init):

	if (efi_poweroff_required())
		pm_power_off = efi_power_off;

The old global pm_power_off handler gets run with a priority of
SYS_OFF_PRIO_DEFAULT which is lower then SYS_OFF_PRIO_FIRMWARE, causing
acpi_power_off() to run first, changing the behavior from before
the ACPI sleep code switched to the new register_sys_off_handler().

Switch the registering of efi_power_off over to register_sys_off_handler()
with a priority of SYS_OFF_PRIO_FIRMWARE + 1 so that it will run before
acpi_power_off() as before.

Note since the new sys-off-handler code will try all handlers in
priority order, there is no more need for the EFI code to store and
call the original pm_power_off handler.

Fixes: 98f30d0e ("ACPI: power: Switch to sys-off handler API")
Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NArd Biesheuvel <ardb@kernel.org>
Link: https://lore.kernel.org/r/20220708131412.81078-3-hdegoede@redhat.com
      d40908f2
    • H
      efi: Fix efi_power_off() not being run before acpi_power_off() when necessary · 650d9a14
      由 Hans de Goede 提交于 
      Commit 98f30d0e ("ACPI: power: Switch to sys-off handler API")
switched the ACPI sleep code from directly setting the old global
pm_power_off handler to using the new register_sys_off_handler()
mechanism with a priority of SYS_OFF_PRIO_FIRMWARE.

This is a problem when the old global pm_power_off handler would later
be overwritten, such as done by the late_initcall(efi_shutdown_init):

	if (efi_poweroff_required())
		pm_power_off = efi_power_off;

The old global pm_power_off handler gets run with a priority of
SYS_OFF_PRIO_DEFAULT which is lower then SYS_OFF_PRIO_FIRMWARE, causing
acpi_power_off() to run first, changing the behavior from before
the ACPI sleep code switched to the new register_sys_off_handler().

Switch the registering of efi_power_off over to register_sys_off_handler()
with a priority of SYS_OFF_PRIO_FIRMWARE + 1 so that it will run before
acpi_power_off() as before.

Note since the new sys-off-handler code will try all handlers in
priority order, there is no more need for the EFI code to store and
call the original pm_power_off handler.

Fixes: 98f30d0e ("ACPI: power: Switch to sys-off handler API")
Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NArd Biesheuvel <ardb@kernel.org>
Link: https://lore.kernel.org/r/20220708131412.81078-3-hdegoede@redhat.com
      650d9a14
  17. 08 7月, 2022 1 次提交
  19. 04 7月, 2022 10 次提交
  21. 30 6月, 2022 1 次提交
  23. 29 6月, 2022 4 次提交
  25. 27 6月, 2022 2 次提交
  27. 26 6月, 2022 2 次提交
  29. 25 6月, 2022 3 次提交
    • A
      efi: vars: Move efivar caching layer into efivarfs · 2d82e622
      由 Ard Biesheuvel 提交于 
      Move the fiddly bits of the efivar layer into its only remaining user,
efivarfs, and confine its use to that particular module. All other uses
of the EFI variable store have no need for this additional layer of
complexity, given that they either only read variables, or read and
write variables into a separate GUIDed namespace, and cannot be used to
manipulate EFI variables that are covered by the EFI spec and/or affect
the boot flow.
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
      2d82e622
    • A
      efi: vars: Drop __efivar_entry_iter() helper which is no longer used · 5ac94136
      由 Ard Biesheuvel 提交于 
      __efivar_entry_iter() uses a list iterator in a dubious way, i.e., it
assumes that the iteration variable always points to an object of the
appropriate type, even if the list traversal exhausts the list
completely, in which case it will point somewhere in the vicinity of the
list's anchor instead.

Fortunately, we no longer use this function so we can just get rid of it
entirely.
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
      5ac94136
    • A
      efi: vars: Switch to new wrapper layer · bbc6d2c6
      由 Ard Biesheuvel 提交于 
      Switch the caching linked-list efivars layer implementation to the newly
introduced efivar get/set variable wrappers, instead of accessing the
lock and the ops pointer directly. This will permit us to move this code
out of the public efivars API, and into efivarfs once the obsolete sysfs
access method is finally removed.
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
      bbc6d2c6