| Age | Commit message (Collapse) | Author |
|---|
|
https://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
# Conflicts:
# Documentation/scheduler/index.rst
# arch/arm64/configs/defconfig
|
|
Since commit 48ebe1cbbeb51 ("kbuild: compress the kernel with pigz if
available"), cmd_gzip runs pigz through scripts/jobserver-exec, which
takes the job slots make has free. GNU Make passes the jobserver pipe
only to recipes it treats as recursive, but leaves --jobserver-auth in
MAKEFLAGS for all of them. The make 4.3 in CentOS Stream 9 also hides
the pipe in sub-makes (a backport of the fix for GNU Make bug 58232), so
jobserver-exec cannot open it, runs pigz on one thread, and prints:
WARNING: Unable to reopen jobserver read-side pipe: FileNotFoundError(2, 'No such file or directory')
Mark every recipe that can run cmd_gzip as recursive with "+", as
commit ecab4115c44cc ("kbuild: mark `rustc` (and others) invocations as
recursive") did for rustc. Besides the $(call if_changed,gzip) rules,
this covers those that choose gzip through a variable: the built-in
initramfs in usr/Makefile (which rcutorture's kvm.sh builds), the EFI
zboot image, and the arm, csky, and mips compressed images. As with
rustc, "make -n" now runs these recipes, including those that choose
through a variable when they select another compressor. Also update the
gzip entry in Documentation/kbuild/makefiles.rst, as suggested in
review.
Tested with GNU Make 4.3 plus CentOS Stream 9's make-4.3-cloexec.patch,
GCC 16.2.0, and -j64, on ARCH=x86_64, arm64, and arm defconfig, and
ARCH=x86_64 defconfig with a built-in initramfs: none of them prints the
warning, and pigz gets the free job slots (-p 54, 64, and 50 for the
kernel image). Without this change, the x86_64 builds print it for the
kernel image and for the initramfs.
Reported-by: Paul E. McKenney <paulmck@kernel.org>
Closes: https://lore.kernel.org/all/0ddb5e5e-f801-444c-aa98-0cfe814a3026@paulmck-laptop/
Fixes: 48ebe1cbbeb51 ("kbuild: compress the kernel with pigz if available")
Assisted-by: LLM
Reviewed-by: Nicolas Schier <n.schier@fritz.com>
Acked-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Signed-off-by: Kees Cook <kees@kernel.org>
Tested-by: Paul E. McKenney <paulmck@kernel.org>
Link: https://patch.msgid.link/20261010081914.540611-1-kees@kernel.org
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
|
|
Every architecture that builds the stub now adds $(DISABLE_KSTACK_ERASE)
to its own flags, so add it once to the flags they share instead.
Assisted-by: LLM
Signed-off-by: Kees Cook <kees@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
The x86 stub replaces KBUILD_CFLAGS with a short list of its own, so new
kernel-wide compiler options go missing, unless explicitly remembered
or when lacking them breaks the build, e.g. commit 5ff8ad3909524
("kbuild: Add '-fms-extensions' to areas with dedicated CFLAGS")
did. Today, several still go missing that are provided to non-x86
stub builds, e.g. -ftrivial-auto-var-init, -fzero-call-used-regs,
-fstrict-flex-arrays=3, and the various kernel's warnings.
Flip the x86 option logic to match the other architectures. Since the
x86 stub is linked into the decompressor rather than the kernel proper,
remove the kernel code model, the i386 register calling convention,
and the kernel's reduced stack alignment, along with the retpoline and
return thunks and the call padding, which only the kernel provides,
and disable kernel stack erasing as the other architectures do. The
existing -mcmodel=small, -march=i386, and -fPIC still get overrides.
Build with -fcf-protection=none, since nothing enables IBT while the
stub runs: the firmware applies forward-edge CFI only to images that
advertise it, which bzImage does not.
New flags that change code generation or semantics in a plain x86_64
defconfig hardening.config stub:
Hardening:
-ftrivial-auto-var-init=zero
-fzero-init-padding-bits=all
-fstrict-flex-arrays=3
-fno-strict-overflow
-fno-delete-null-pointer-checks
-fno-allow-store-data-races
-fno-jump-tables (from the default IBT config)
C semantics:
-funsigned-char
-fno-common
x86 code generation:
-mno-sse2 -mno-3dnow -mno-avx -mno-sse4a
(stub already added -mno-mmx -mno-sse)
-mno-80387 -mno-fp-ret-in-387 -mskip-rax-setup
-falign-jumps=1 -falign-loops=1 -fmin-function-alignment=16
-fomit-frame-pointer -fconserve-stack
-fno-stack-clash-protection -fno-stack-check -fno-builtin-wcslen
Warnings (lots and lots, but notably):
-Wall -Wextra -Wundef -Wmissing-prototypes
-Wvla-larger-than=1 -Wimplicit-fallthrough=5
Present but with no effect, because the stub's later flags override them:
-O2, overridden by -Os
-fstack-protector-* flags, overridden by -fno-stack-protector
-fno-PIE, overridden by -fPIC
-fcf-protection=branch, overridden by -fcf-protection=none
the stack-erase plugin, loaded and then disabled
Build tested ARCH=x86_64 defconfig hardening.config, plus retpolines,
return thunks, call depth tracking, IBT, GCC plugins, and EFI mixed
mode, with GCC 16.2.0 and Clang 24.0.0git, and ARCH=i386 defconfig
hardening.config with GCC 16.2.0. Each booted through the EFI stub to
userspace under QEMU with x64 and IA32 OVMF, the latter in mixed mode
for x86_64.
Assisted-by: LLM
Signed-off-by: Kees Cook <kees@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
efi_stub_entry() and efi_handover_entry() are entered from efi-mixed.S
and, through the efi32_stub_entry() and efi64_stub_entry() aliases, by
boot loaders using the EFI handover protocol, but have no prototypes.
Declare them in x86-stub.h, as asmlinkage, so that the stub can be built
with the kernel's -Wmissing-prototypes.
Assisted-by: LLM
Signed-off-by: Kees Cook <kees@kernel.org>
[ardb: fix i386 GCC build by scoping to CONFIG_EFI_MIXED=y]
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
Sashiko points out that efi_handle_cmdline() allocates this memory and
hands it over to the caller. If efi_pe_entry() ever returns it should be
freed. Add a __free annotation.
Fixes: 42c8ea3dca09 ("efi: libstub: Factor out EFI stub entrypoint into separate file")
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
Sashiko points out the image_size should only be set if image_addr was
reassigned to some allocated memory. If image_size is not zero then the
caller will free the image_addr pointer.
efi_kaslr_relocate_kernel() never works like that, if it changes
image_addr to allocated memory the free is done through reserve_size.
Fixes: b7ac4b8ee73d ("riscv: libstub: Implement KASLR by using generic functions")
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
Sashiko says fdt_addr can point to either an allocated fdt or the fdt from
get_fdt() which is memory owned by FW.
Only the allocated fdt should be freed on the error unwind path. Use a
dedicated variable for the allocation's size so that the free does not get
confused.
Fixes: 4fc8e738ff3e ("efi: libstub: remove DT dependency from generic stub")
Reviewed-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
|
|
The Boot Loader Interface (BLI) [1] defines EFI variables that expose
boot loader state to the running OS. LoaderInfo identifies the boot
loader, while LoaderDevicePartUUID records the GPT partition UUID of
the partition containing it.
LoaderDevicePartUUID is used, for example, by systemd-gpt-auto-generator
[2] to identify the disk the boot loader was launched from and
automatically detect and mount partitions on it.
GRUB [3] and systemd-boot [4] populate these variables, but when the
kernel is started directly by EFI firmware, there is no conventional
external boot loader to provide them. In that case, because the EFI stub
performs the boot loader role, it should provide the variables itself.
Use LoaderInfo as a sentinel: if it is already set by an earlier boot
stage or cannot be set, bail out. Otherwise, populate the other BLI
variables.
Parse the loaded image device path, extract the GUID signature from its
GPT HD() node and publish it under the Linux loader entry vendor GUID as
the volatile LoaderDevicePartUUID EFI variable.
Install the efi_bli_set_variables() hook in both the generic efi-stub.c
path and the x86-specific x86-stub.c path.
[1] The Boot Loader Interface
Link: https://systemd.io/BOOT_LOADER_INTERFACE/
[2] systemd-gpt-auto-generator
Link: https://www.freedesktop.org/software/systemd/man/latest/systemd-gpt-auto-generator.html
[3] GRUB -- §16.2 bli
Link: https://www.gnu.org/software/grub/manual/grub/html_node/bli_005fmodule.html
[4] systemd -- systemd-boot UEFI Boot Manager
Link: https://github.com/systemd/systemd/blob/main/docs/BOOT.md?plain=1#L102
Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
[ardb: - constify 'image' pointer parameter
- pass efi_guid_t* to efi_snprintf()]
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
The native EFI character set is UTF-16 (or in practice, UCS-2).
Implement efi_snprintf() to construct UTF-16 strings using printf style
templates. This will be used in a subsequent patch to set the
LoaderDevicePartUUID EFI variable.
Reviewed-by: Vincent Mailhol <mailhol@kernel.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
Add support for the %pUl printk conversion specifier, which takes a
pointer to a GUID and prints it in the usual format:
aaaaaaaa-bbbb-cccc-dddd-dddddddddddd
Co-developed-by: Vincent Mailhol <mailhol@kernel.org>
Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
Reviewed-by: Vincent Mailhol <mailhol@kernel.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
The only remaining users of vsnprintf() in the EFI stub are the
diagnostic printk()'s, which are emitted to the console and not recorded
for posterity.
The EFI console uses UTF-16 (or actually, UCS-2) natively, and so all
non-UTF16 strings that are emitted need to be converted. Given the
stub's vsnprintf() support for wide strings (using the %ls conversion
modifier), which uses UTF-16 to UTF-8 conversion internally, the final
conversion to UTF-16 needs to support not just plain ASCII but UTF-8 as
well.
This is all pointless, of course, and it makes more sense to use UTF-16
internally. This removes the need for UTF-16 to UTF-8 conversion in
vsnprintf(), and given that all non-wide string inputs to vsnprintf()
that exist in the stub today are compile time constant ASCII strings,
the need to convert UTF-8 to UTF-16 disappears as well.
So implement efi_vsnprintf() taking a const char *fmt as before, but
outputting a efi_char16_t[] that can be passed to the EFI console
directly, rather than via efi_puts(), leaving the latter unused and
therefore removed.
Note that efi_puts() performs LF to CR-LF conversion internally, so add
this capability to efi_vsnprintf() as well.
Reviewed-by: Vincent Mailhol <mailhol@kernel.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
efi_puts() performs a UTF-8 to UTF-16 conversion on its input, as the
EFI console's native character set is UTF-16.
This is pointless for compile time constant strings, since we can
simply define those as UTF-16 to begin with. This takes slightly more
space, but removes any runtime handling of those strings, simplifying
the code.
Note that efi_puts() also performs LF to CR-LF conversion, so this needs
to be taken into account as well.
Reviewed-by: Vincent Mailhol <mailhol@kernel.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
Don't rely on sprintf() with a wide string conversion modifier to
convert the command line from UTF-16 to UTF-8. Instead, use the
existing ucs2 string library routine that does the same. Note that while
UEFI claims support for UTF-16, in practice it ignores surrogate pairs
entirely, and so the simplified UCS-2 character set (where each
character takes up exactly 2 bytes) is sufficient here.
This removes the only user of sprintf() in the EFI stub, so drop that
function as well.
Since boot memory is plentiful on UEFI systems, just establish a worst
case upper bound for the size of the buffer (which can never exceed
COMMAND_LINE_SIZE), and allocate that first. Then, perform the
conversion, and only fall back to processing the command line character
by character if that resulted in truncation. This makes the common
execution path much simpler.
Note that this no longer truncates the command line at the first
newline, but there is no evidence that this has ever been needed.
Reviewed-by: Vincent Mailhol <mailhol@kernel.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
arch_accept_memory() is an arch-specific hook that is required by the
EFI stub when processing memory that the firmware reports to the OS as
EFI_UNACCEPTED_MEMORY.
This hook is called after ExitBootServices() has been called, as before
that point, the EFI memory map may get updated behind the back of the
running EFI stub, making it difficult to get a stable view on it while
iterating over the entries.
Currently, the x86 version of this hook is implemented in its
decompressor rather than in the EFI stub itself, in a manner that is
problematic: when an error occurs, it calls the decompressor's error()
routine, but without having gone through the decompressor initialization
code. This means it will resort to direct port I/O rather than the
hypercall based interface that TDX guests would use otherwise.
Conceptually, code that is only called from the EFI stub, and never by
the decompressor when doing legacy boot, belongs in the EFI stub and not
in the decompressor.
So move it into the x86-specific EFI stub code, replacing the error() on
the TDX path with tdx_panic(), and dropping the error() when no CC
support is detected - the kernel can decide what to do in this case
after it has booted.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Kiryl Shutsemau (Meta) <kas@kernel.org>
Link: https://patch.msgid.link/20260925075137.44298-7-ardb@kernel.org
|
|
Each kernel make invocation begins with ~30 compiler and linker runs each
of which performs duplicate probe for a number of compiler and linker
options.
This is useless work - the compiler and its version is known, so use these
to determine which options are available, once.
Using the newly introduced cc-option-str, track the result of each probe in
CC_OPT_*, LD_OPT_* variables and have Makefile's simply append the symbol.
Some care has to be taken around negative options, i.e. -Wno-xxx, as gcc
accepts an unknown -Wno- without complaint and only complains later, so
instead probe the positive form for these cases.
Use CC_HAS_* For those probes that gate a Makefile conditional rather than
a simple option, as per the established pattern for this.
This change avoids a subtle issue with ppc32 (big endian) - clang doesn't
accept -fno-stack-clash-protection on this sub-target, so keep this option
in the Makefile.
With gcc and clang, defconfig and allmodconfig, the recorded command
lines are unchanged, a build with nothing to do rebuilds nothing and W=1
continues to function correctly.
Doing this improves all builds, but has a particularly positive impact on
no-op builds (builds where nothing has changed).
Whole build, 128-thread Threadripper 9980X, best of N runs:
before after delta
-------------------------------
x86 defconfig, no-op make, gcc 0.78s 0.60s -0.18s (-23%)
x86 defconfig, no-op make, clang 0.94s 0.66s -0.28s (-30%)
x86 defconfig, touch mm/vma.c, gcc 8.6s 8.5s -0.16s (-2%)
x86 defconfig, touch mm/vma.c, clang 8.0s 7.7s -0.24s (-3%)
x86 defconfig, clean, clang 29.8s 29.4s -0.37s (-1%)
x86 allmodconfig, no-op make, gcc 12.9s 12.7s -0.23s (-2%)
x86 allmodconfig, no-op make, clang 14.2s 13.9s -0.29s (-2%)
x86 allmodconfig, touch mm/vma.c, clang 32.2s 31.9s -0.30s (-1%)
Assisted-by: LLM
Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Link: https://patch.msgid.link/20260923-build-speedup-v4-12-73128809a4a4@kernel.org
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
|
|
Fix the grammar in the kernel-doc comment and indent the @image_addr
description correctly.
Signed-off-by: Thorsten Blum <blum@kernel.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
Drop the local ret variable and the break statement by returning the
result directly. Also use unsigned long for map_offset, since map_size
and desc_size are both unsigned long.
Signed-off-by: Thorsten Blum <blum@kernel.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
alloc_e820ext() and setup_e820() use sizeof(struct e820_entry) when
calculating the sizes of boot_e820_entry structures.
Even though struct e820_entry and struct boot_e820_entry have the same
size, use sizeof(struct boot_e820_entry) for consistency instead.
Signed-off-by: Thorsten Blum <blum@kernel.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
efi_set_event_at() documents ids although its array index argument is
named idx. This produces missing and excess parameter warnings.
Match the argument name and fix the adjacent spelling of array.
Fixes: 8c0a839c2bcc ("efi/libstub: Descriptions for stub helper functions")
Assisted-by: LLM
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
Some GUIDs are used several times in the same translation unit.
Factor the duplicated EFI_FILE_SYSTEM_GUID, EFI_RNG_PROTOCOL_GUID and
EFI_GRAPHICS_OUTPUT_PROTOCOL_GUID objects at file scope within their
translation units. Leave the single-use GUID objects at function scope.
For an x86_64 build with gcc 15.3.0, bloat-o-meter reports:
add/remove: 0/0 grow/shrink: 0/3 up/down: 0/-48 (-48)
Function old new delta
rng_proto 32 16 -16
graphics_output_guid 32 16 -16
fs_proto 32 16 -16
Total: Before=28471, After=28423, chg -0.17%
Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
Local efi_guid_t variables with automatic storage produce assembly
similar to passing the address of the GUID macro directly. For the same
reason, make these GUID variables static.
Put the static declarations first in their local declaration block to
visually separate them from the automatic variables.
For an x86_64 build with gcc 15.3.0, bloat-o-meter reports:
add/remove: 15/0 grow/shrink: 0/10 up/down: 336/-742 (-406)
Function old new delta
tbl_guid - 32 +32
rng_proto - 32 +32
pci_proto - 32 +32
guid - 32 +32
fs_proto - 32 +32
cc_guid - 32 +32
tpm2_guid - 16 +16
text_to_dp_guid - 16 +16
tcg2_guid - 16 +16
rng_table_guid - 16 +16
rng_algo_raw - 16 +16
proto - 16 +16
linux_eventlog_guid - 16 +16
lf2_proto_guid - 16 +16
info_guid - 16 +16
efi_get_memory_map 707 696 -11
efi_pci_disable_bridge_busmaster 1199 1184 -15
efi_get_random_bytes 216 188 -28
efi_remap_image 357 328 -29
efi_load_initrd 1113 1065 -48
efi_random_get_seed 1368 1297 -71
efi_measure_tagged_event 935 854 -81
efi_retrieve_eventlog 1686 1570 -116
handle_cmdline_files 2501 2341 -160
efi_stub_entry 4136 3953 -183
Total: Before=28877, After=28471, chg -1.41%
Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
Some EFI stub call sites pass the address of a GUID macro directly to
EFI boot services. With gcc, this makes the compiler materialize the
GUID data at the call site, which is wasteful in the size-sensitive EFI
stub.
For example, consider this program:
#include <linux/efi.h>
#define GUID \
EFI_GUID(0xaaaaaaaa, 0xbbbb, 0xcccc, \
0xdd, 0xdd, 0xdd, 0xdd, 0xdd, 0xdd, 0xdd, 0xdd)
void foo(const efi_guid_t *guid);
void guid_direct(void)
{
foo(&GUID);
}
void guid_static(void)
{
static efi_guid_t guid = GUID;
foo(&guid);
}
For guid_direct(), gcc materializes the GUID on the stack:
0: f3 0f 1e fa endbr64
4: 48 b8 aa aa aa aa bb movabs $0xccccbbbbaaaaaaaa,%rax
b: bb cc cc
e: 48 83 ec 18 sub $0x18,%rsp
12: 48 89 04 24 mov %rax,(%rsp)
16: 48 89 e7 mov %rsp,%rdi
19: 48 b8 dd dd dd dd dd movabs $0xdddddddddddddddd,%rax
20: dd dd dd
23: 48 89 44 24 08 mov %rax,0x8(%rsp)
28: e8 00 00 00 00 call 2d <guid_direct+0x2d>
2d: 48 83 c4 18 add $0x18,%rsp
31: c3 ret
For guid_static(), gcc stores the GUID in .data and emits a RIP-relative
address load:
32: f3 0f 1e fa endbr64
36: 48 8d 3d 00 00 00 00 lea 0x0(%rip),%rdi
3d: e9 00 00 00 00 jmp 42 <guid_static+0x10>
Overall, guid_direct() consumes 50 bytes in the .text segment whereas
guid_static() needs only 32 bytes in total: 16 bytes in .data and 16
bytes in .text.
Move these direct GUID references to function-local static objects and
pass their address instead. EFI boot service prototypes take non-const
efi_guid_t pointers, so keep the GUID non-const to prevent a
-Wdiscarded-qualifiers warning.
For an x86_64 build with gcc 15.3.0, bloat-o-meter reports:
add/remove: 6/0 grow/shrink: 0/3 up/down: 112/-458 (-346)
Function old new delta
graphics_output_guid - 32 +32
smbios_guid - 16 +16
edid_discovered_guid - 16 +16
edid_active_guid - 16 +16
console_out_device_guid - 16 +16
apple_set_os_guid - 16 +16
efi_stub_entry 4180 4136 -44
efi_get_smbios_record 283 226 -57
efi_setup_graphics 2210 1853 -357
Total: Before=29223, After=28877, chg -1.18%
Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Pull non-MM updates from Andrew Morton:
- "taskstats: fix TGID dead-thread stat retention" (Yiyang Chen)
Fix a taskstats TGID aggregation bug where fields added in the TGID
query path were not preserved after thread exit, and adds a kselftest
covering the regression.
- "lib/tests: string_helpers: Slight improvements" (Andy Shevchenko)
Improve lib/tests/string_helpers_kunit.c a little
- "lib/base64: decode fixes" (Josh Law)
Address minor issues in lib/base64.c
- "selftests/filelock: Make output more kselftestish" (Mark Brown)
Make the output from the ofdlocks test a bit easier for tooling to
work with. Also ignore the generated file
- "uaccess: unify inline vs outline copy_{from,to}_user() selection"
(Yury Norov)
Simplify the usercopy code by removing the selectability of inlining
copy_{from,to}_user().
- "ocfs2: validate inline xattr header consumers" (ZhengYuan Huang)
Fix a number of possible issues in the ocfs2 xattr code
- "lib and lib/cmdline enhancements" (Dmitry Antipov)
Provide additional robustness checking in the cmdline handling code
and its in-kernel testing and selftests
- "cleanup the RAID6 P/Q library" (Christoph Hellwig)
Clean up the RAID6 P/Q library to match the recent updates to the
RAID 5 XOR library and other CRC/crypto libraries
- "ocfs2: harden inode validators against forged metadata" (Michael
Bommarito)
Add three structural checks to OCFS2 dinode validation so malformed
on-disk fields are rejected before ocfs2_populate_inode() copies them
into the in-core inode
- "lib/raid: replace __get_free_pages() call with kmalloc()" (Mike
Rapoport)
Clean up the lib/raid code by using kmalloc() in more places
* tag 'mm-nonmm-stable-2026-06-21-10-22' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: (108 commits)
ocfs2: fix circular locking dependency in ocfs2_dio_end_io_write
ocfs2: fix NULL h_transaction deref in ocfs2_assure_trans_credits
lib: interval_tree_test: validate benchmark parameters
ocfs2: avoid moving extents to occupied clusters
treewide: fix transposed "sign" typos and update spelling.txt
ocfs2: fix UBSAN array-index-out-of-bounds in ocfs2_sum_rightmost_rec
fat: reject BPB volumes whose data area starts beyond total sectors
selftests/uevent: increase __UEVENT_BUFFER_SIZE to avoid ENOBUFS on busy systems
lib/test_firmware: allocate the configured into_buf size
fs: efs: remove unneeded debug prints
checkpatch: cuppress warnings when Reported-by: is followed by Link:
MAINTAINERS: add Alexander as a kcov reviewer
mailmap: update Alexander Sverdlin's Email addresses
fs: fat: inode: replace sprintf() with scnprintf()
ocfs2: fix out-of-bounds write in ocfs2_remove_refcount_extent
ocfs2: fix race between ocfs2_control_install_private() and ocfs2_control_release()
ocfs2/dlm: require a ref for locking_state debugfs open
ocfs2: reject FITRIM ranges shorter than a cluster
ocfs2: validate fast symlink target during inode read
ocfs2: add journal NULL check in ocfs2_checkpoint_inode()
...
|
|
gitolite.kernel.org:pub/scm/linux/kernel/git/tip/tip
Pull x86 cpuid updates from Ingo Molnar:
- CPUID API updates (Ahmed S. Darwish):
- Introduce a centralized CPUID parser
- Introduce a centralized CPUID data model
- Introduce <asm/cpuid/leaf_types.h>
- Rename cpuid_leaf()/cpuid_subleaf() APIs
- treewide: Explicitly include the x86 CPUID headers
- Update to x86-cpuid-db v3.1 (Maciej Wieczor-Retman)
- Continued removal of pre-i586 support and related simplifications
(Ingo Molnar)
- Add Intel CPU model number for rugged Panther Lake (Tony Luck)
- Misc fixes, updates and cleanups by Arnd Bergmann, Chao Gao, Lukas
Bulwahn, Sohil Mehta, Maciej Wieczor-Retman.
* tag 'x86-cpu-2026-06-14' of gitolite.kernel.org:pub/scm/linux/kernel/git/tip/tip: (25 commits)
x86/cpu: Make CONFIG_X86_CX8 unconditional
x86/cpu: Remove unused !CONFIG_X86_TSC code
x86/cpuid: Update bitfields to x86-cpuid-db v3.1
tools/x86/kcpuid: Update bitfields to x86-cpuid-db v3.1
x86/cpu: Make CONFIG_X86_TSC unconditional
MAINTAINERS: Drop obsolete FPU EMULATOR section
x86/cpu: Fix a F00F bug warning and clean up surrounding code
x86/cpu: Add Intel CPU model number for rugged Panther Lake
x86/cpuid: Introduce a centralized CPUID parser
x86/cpu: Introduce a centralized CPUID data model
x86/cpuid: Introduce <asm/cpuid/leaf_types.h>
x86/cpuid: Rename cpuid_leaf()/cpuid_subleaf() APIs
x86/cpu: Do not include the CPUID API header in asm/processor.h
Documentation: core-api/cpu_hotplug: Remove stale cpu0_hotplug docs
x86/cpu, cpufreq: Remove AMD ELAN support
x86/fpu: Remove the math-emu/ FPU emulation library
x86/fpu: Remove the 'no387' boot option
x86/fpu: Remove MATH_EMULATION and related glue code
treewide: Explicitly include the x86 CPUID headers
x86/cpu: Remove the CONFIG_X86_INVD_BUG quirk
...
|
|
When building vmlinuz.efi with CONFIG_EFI_ZBOOT enabled, '__lshrdi3()'
is also needed to fix yet another link error observed when building
riscv32 and loongarch32 images:
riscv32-linux-gnu-ld: drivers/firmware/efi/libstub/lib-cmdline.stub.o: in function `__efistub_.L49':
__efistub_cmdline.c:(.init.text+0x202): undefined reference to `__efistub___lshrdi3'
/usr/bin/loongarch32-linux-gnu-ld: ./drivers/firmware/efi/libstub/lib-cmdline.stub.o: in function `__efistub_.L47':
__efistub_cmdline.c:(.init.text+0x26c): undefined reference to `__efistub___lshrdi3'
And since both riscv64 and loongarch64 can have CONFIG_EFI_ZBOOT but
doesn't need these library routines, rely on CONFIG_32BIT to manage
linking of lib-ashldi3.o and lib-lshrdi3.o on 32-bit variants only.
[dmantipov@yandex.ru: fix loongarch32]
Link: https://lore.kernel.org/8095016e47aceab4830c2523ce78af968ec0497e.camel@yandex.ru
Link: https://lore.kernel.org/20260519172259.908980-9-dmantipov@yandex.ru
Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
Reported-by: Charlie Jenkins <thecharlesjenkins@gmail.com>
Closes: https://lore.kernel.org/linux-riscv/20260409050018.GA371560@inky.localdomain
Tested-by: Charlie Jenkins <thecharlesjenkins@gmail.com>
Suggested-by: Ard Biesheuvel <ardb@kernel.org>
Assisted-by: Gemini:gemini-3.1-pro-preview sashiko
Tested-by: Charlie Jenkins <thecharlesjenkins@gmail.com>
Cc: Albert Ou <aou@eecs.berkeley.edu>
Cc: Alexandre Ghiti <alex@ghiti.fr>
Cc: Andriy Shevchenko <andriy.shevchenko@intel.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
|
|
Introduce efi_get_kimg_kaslr_address() helper to compute the preferred
kernel image load address dynamically when CONFIG_RANDOMIZE_BASE is
enabled. The function derives a random offset by using the EFI-provided
randomness combined with the timer tick value, and constrains it within
CONFIG_RANDOMIZE_BASE_MAX_OFFSET.
Update EFI_KIMG_PREFERRED_ADDRESS to call this helper so that the EFI
stub can select a randomized load address when KASLR is active, while
preserving the original base address behavior when KASLR is disabled or
"nokaslr" is specified.
Note: LoongArch can't KASLR for hibernation, so set efi_nokaslr to true
if "resume=<devname>" is explicitly specified in cmdline.
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: WANG Rui <wangrui@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
|
|
Modify all CPUID call sites which implicitly include any of the CPUID
headers to explicitly include them instead.
For KVM's reverse_cpuid.h, just include <asm/cpuid/types.h> since it
references the CPUID_EAX..EDX symbols without using the CPUID APIs.
Note, this allows removing the inclusion of <asm/cpuid/api.h> from within
<asm/processor.h> next. That allows the CPUID API headers to include
<asm/processor.h> without introducing a circular dependency.
Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/20260327021645.555257-1-darwi@linutronix.de
|
|
The relocated kernel image is copied to its new location using memcpy().
On architectures with separate instruction and data caches, the copied
instructions may remain stale in the instruction cache, leading to the
execution of outdated contents.
Call efi_cache_sync_image() after the relocation copy to ensure the
instruction cache is synchronized with the updated memory contents before
control is transferred to the relocated kernel.
Signed-off-by: WANG Rui <r@hev.cc>
Reviewed-by: Huacai Chen <chenhuacai@loongson.cn>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
Provide a LoongArch implementation of efi_cache_sync_image() to ensure
instruction cache coherency after the kernel image is relocated.
Signed-off-by: WANG Rui <r@hev.cc>
Reviewed-by: Huacai Chen <chenhuacai@loongson.cn>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
LoongArch is the only arch that still uses efi_relocate_kernel(), so
before making changes to it that LoongArch needs, turn it into a private
function. Move efi_low_alloc_above() into mem.c while at it, and drop
the relocate.c source file altogether.
Tested-by: WANG Rui <wangrui@loongson.cn>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson
Pull LoongArch updates from Huacai Chen:
- Adjust build infrastructure for 32BIT/64BIT
- Add HIGHMEM (PKMAP and FIX_KMAP) support
- Show and handle CPU vulnerabilites correctly
- Batch the icache maintenance for jump_label
- Add more atomic instructions support for BPF JIT
- Add more features (e.g. fsession) support for BPF trampoline
- Some bug fixes and other small changes
* tag 'loongarch-7.1' of git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson: (21 commits)
selftests/bpf: Enable CAN_USE_LOAD_ACQ_STORE_REL for LoongArch
LoongArch: BPF: Add fsession support for trampolines
LoongArch: BPF: Introduce emit_store_stack_imm64() helper
LoongArch: BPF: Support up to 12 function arguments for trampoline
LoongArch: BPF: Support small struct arguments for trampoline
LoongArch: BPF: Open code and remove invoke_bpf_mod_ret()
LoongArch: BPF: Support load-acquire and store-release instructions
LoongArch: BPF: Support 8 and 16 bit read-modify-write instructions
LoongArch: BPF: Add the default case in emit_atomic() and rename it
LoongArch: Define instruction formats for AM{SWAP/ADD}.{B/H} and DBAR
LoongArch: Batch the icache maintenance for jump_label
LoongArch: Add flush_icache_all()/local_flush_icache_all()
LoongArch: Add spectre boundry for syscall dispatch table
LoongArch: Show CPU vulnerabilites correctly
LoongArch: Make arch_irq_work_has_interrupt() true only if IPI HW exist
LoongArch: Use get_random_canary() for stack canary init
LoongArch: Improve the logging of disabling KASLR
LoongArch: Align FPU register state to 32 bytes
LoongArch: Handle CONFIG_32BIT in syscall_get_arch()
LoongArch: Add HIGHMEM (PKMAP and FIX_KMAP) support
...
|
|
Adjust build infrastructure (Kconfig, Makefile and ld scripts) to let
us enable both 32BIT/64BIT kernel build.
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi
Pull EFI updates from Ard Biesheuvel:
"Again not a busy cycle for EFI, just some minor tweaks and bug fixes:
- Enable boot graphics resource table (BGRT) on Xen/x86
- Correct a misguided assumption in the memory attributes table
sanity check
- Start tagging efi_mem_reserve()'d regions as MEMBLOCK_RSRV_KERN
- Some other minor fixes and cleanups"
* tag 'efi-next-for-v7.1' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi:
efi/capsule-loader: fix incorrect sizeof in phys array reallocation
efi: Tag memblock reservations of boot services regions as RSRV_KERN
memblock: Permit existing reserved regions to be marked RSRV_KERN
efi/memattr: Fix thinko in table size sanity check
efi: libstub: fix type of fdt 32 and 64bit variables
efi: Drop unused efi_range_is_wc() function
efi: Enable BGRT loading under Xen
efi: make efi_mem_type() and efi_mem_attributes() work on Xen PV
|
|
Introduce CC_FLAGS_DIALECT to make it easier to update the various
places in the tree that rely on the GNU C standard and Microsoft
extensions flags atomically. All remaining uses of '-std=gnu11' and
'-fms-extensions' are in the tools directory (which has its own build
system) and other standalone Makefiles. This will allow the kernel to
use a narrower option to enable the Microsoft anonymous tagged structure
extension in a simpler manner. Place the CC_FLAGS_DIALECT block after
the configuration include (so that a future change can move the
selection of the flag to Kconfig) but before the
arch/$(SRCARCH)/Makefile include (so that CC_FLAGS_DIALECT is available
for use in those Makefiles).
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Nicolas Schier <nsc@kernel.org>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Helge Deller <deller@gmx.de> # parisc
Link: https://patch.msgid.link/20260223-fms-anonymous-structs-v1-1-8ee406d3c36c@kernel.org
Signed-off-by: Nicolas Schier <nsc@kernel.org>
|
|
In update_fdt_memmap() an update_fdt() the fdt values should be
of the fd32_t and fdt64_t types. Make the relevant changes to
remove the following sparse warnings:
drivers/firmware/efi/libstub/fdt.c:97:19: warning: incorrect type in assignment (different base types)
drivers/firmware/efi/libstub/fdt.c:97:19: expected unsigned long long [usertype] fdt_val64
drivers/firmware/efi/libstub/fdt.c:97:19: got restricted __be64 [usertype]
drivers/firmware/efi/libstub/fdt.c:157:19: warning: incorrect type in assignment (different base types)
drivers/firmware/efi/libstub/fdt.c:157:19: expected unsigned long long [usertype] fdt_val64
drivers/firmware/efi/libstub/fdt.c:157:19: got restricted __be64 [usertype]
drivers/firmware/efi/libstub/fdt.c:163:19: warning: incorrect type in assignment (different base types)
drivers/firmware/efi/libstub/fdt.c:163:19: expected unsigned int [usertype] fdt_val32
drivers/firmware/efi/libstub/fdt.c:163:19: got restricted __be32 [usertype]
drivers/firmware/efi/libstub/fdt.c:169:19: warning: incorrect type in assignment (different base types)
drivers/firmware/efi/libstub/fdt.c:169:19: expected unsigned int [addressable] [usertype] fdt_val32
drivers/firmware/efi/libstub/fdt.c:169:19: got restricted __be32 [usertype]
drivers/firmware/efi/libstub/fdt.c:175:19: warning: incorrect type in assignment (different base types)
drivers/firmware/efi/libstub/fdt.c:175:19: expected unsigned int [addressable] [usertype] fdt_val32
drivers/firmware/efi/libstub/fdt.c:175:19: got restricted __be32 [usertype]
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi
Pull EFI updates from Ard Biesheuvel:
- Quirk the broken EFI framebuffer geometry on the Valve Steam Deck
- Capture the EDID information of the primary display also on non-x86
EFI systems when booting via the EFI stub.
* tag 'efi-next-for-v7.0' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi:
efi: Support EDID information
sysfb: Move edid_info into sysfb_primary_display
sysfb: Pass sysfb_primary_display to devices
sysfb: Replace screen_info with sysfb_primary_display
sysfb: Add struct sysfb_display_info
efi: sysfb_efi: Reduce number of references to global screen_info
efi: earlycon: Reduce number of references to global screen_info
efi: sysfb_efi: Fix efidrmfb and simpledrmfb on Valve Steam Deck
efi: sysfb_efi: Convert swap width and height quirk to a callback
efi: sysfb_efi: Fix lfb_linelength calculation when applying quirks
efi: sysfb_efi: Replace open coded swap with the macro
|
|
The efi_edid_discovered_protocol and efi_edid_active_protocol have mixed
mode fields. So all their attributes should be accessed through
the efi_table_attr() helper.
Doing so fixes the upper 32 bits of the 64 bit gop_edid pointer getting
set to random values (followed by a crash at boot) when booting a x86_64
kernel on a machine with 32 bit UEFI like the Asus T100TA.
Fixes: 17029cdd8f9d ("efi/libstub: gop: Add support for reading EDID")
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Javier Martinez Canillas <javierm@redhat.com>
Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
In the EFI config table, rename LINUX_EFI_SCREEN_INFO_TABLE_GUID to
LINUX_EFI_PRIMARY_DISPLAY_TABLE_GUID. Read sysfb_primary_display from
the entry. In addition to the screen_info, the entry now also contains
EDID information.
In libstub, replace struct screen_info with struct sysfb_display_info
from the kernel's sysfb_primary_display and rename functions
accordingly. Transfer it to the runtime kernel using the kernel's
global state or the LINUX_EFI_PRIMARY_DISPLAY_TABLE_GUID config-table
entry.
With CONFIG_FIRMWARE_EDID=y, libstub now transfers the GOP device's EDID
information to the kernel. If CONFIG_FIRMWARE_EDID=n, EDID information
is disabled. Make the Kconfig symbol CONFIG_FIRMWARE_EDID available with
EFI. Setting the value to 'n' disables EDID support.
Also rename screen_info.c to primary_display.c and adapt the contained
comment according to the changes.
Link: https://lore.kernel.org/all/20251126160854.553077-8-tzimmermann@suse.de/
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
[ardb: depend on EFI_GENERIC_STUB not EFI, fix conflicts after dropping
the preceding patch from the series]
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
Replace the global screen_info with sysfb_primary_display of type
struct sysfb_display_info. Adapt all users of screen_info.
Instances of screen_info are defined for x86, loongarch and EFI,
with only one instance compiled into a specific build. Replace all
of them with sysfb_primary_display.
All existing users of screen_info are updated by pointing them to
sysfb_primary_display.screen instead. This introduces some churn to
the code, but has no impact on functionality.
Boot parameters and EFI config tables are unchanged. They transfer
screen_info as before. The logic in EFI's alloc_screen_info() changes
slightly, as it now returns the screen field of sysfb_primary_display.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Bjorn Helgaas <bhelgaas@google.com> # drivers/pci/
Reviewed-by: Richard Lyu <richard.lyu@suse.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson
Pull LoongArch updates from Huacai Chen:
- Add basic LoongArch32 support
Note: Build infrastructures of LoongArch32 are not enabled yet,
because we need to adjust irqchip drivers and wait for GNU toolchain
be upstream first.
- Select HAVE_ARCH_BITREVERSE in Kconfig
- Fix build and boot for CONFIG_RANDSTRUCT
- Correct the calculation logic of thread_count
- Some bug fixes and other small changes
* tag 'loongarch-6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson: (22 commits)
LoongArch: Adjust default config files for 32BIT/64BIT
LoongArch: Adjust VDSO/VSYSCALL for 32BIT/64BIT
LoongArch: Adjust misc routines for 32BIT/64BIT
LoongArch: Adjust user accessors for 32BIT/64BIT
LoongArch: Adjust system call for 32BIT/64BIT
LoongArch: Adjust module loader for 32BIT/64BIT
LoongArch: Adjust time routines for 32BIT/64BIT
LoongArch: Adjust process management for 32BIT/64BIT
LoongArch: Adjust memory management for 32BIT/64BIT
LoongArch: Adjust boot & setup for 32BIT/64BIT
LoongArch: Adjust common macro definitions for 32BIT/64BIT
LoongArch: Add adaptive CSR accessors for 32BIT/64BIT
LoongArch: Add atomic operations for 32BIT/64BIT
LoongArch: Add new PCI ID for pci_fixup_vgadev()
LoongArch: Add and use some macros for AVEC
LoongArch: Correct the calculation logic of thread_count
LoongArch: Use unsigned long for _end and _text
LoongArch: Use __pmd()/__pte() for swap entry conversions
LoongArch: Fix arch_dup_task_struct() for CONFIG_RANDSTRUCT
LoongArch: Fix build errors for CONFIG_RANDSTRUCT
...
|
|
32BIT platforms only have 32bit CSR/IOCSR registers, 64BIT platforms
have both 32bit/64bit CSR/IOCSR registers. Now there are both 32bit and
64bit CSR accessors:
csr_read32()/csr_write32()/csr_xchg32();
csr_read64()/csr_write64()/csr_xchg64();
Some CSR registers (address and timer registers) are 32bit length on
32BIT platform and 64bit length on 64BIT platform. To avoid #ifdefs here
and there, they need adaptive accessors, so we define and use:
csr_read()/csr_write()/csr_xchg();
IOCSR doesn't have a "natural length", which means a 64bit register can
be treated as two 32bit registers, so we just use two 32bit accessors to
emulate a 64bit accessors.
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi
Pull EFI updates from Ard Biesheuvel:
"The usual trickle of EFI contributions:
- Parse SMBIOS tables in memory directly on Macbooks that do not
implement the EFI SMBIOS protocol
- Obtain EDID information from the primary display while running in
the EFI stub, and expose it via bootparams on x86 (generic method
is in the works, and will likely land during the next cycle)
- Bring CPER handling for ARM systems up to data with the latest EFI
spec changes
- Various cosmetic changes"
* tag 'efi-next-for-v6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi:
docs: efi: add CPER functions to driver-api
efi/cper: align ARM CPER type with UEFI 2.9A/2.10 specs
efi/cper: Add a new helper function to print bitmasks
efi/cper: Adjust infopfx size to accept an extra space
RAS: Report all ARM processor CPER information to userspace
efi/libstub: x86: Store EDID in boot_params
efi/libstub: gop: Add support for reading EDID
efi/libstub: gop: Initialize screen_info in helper function
efi/libstub: gop: Find GOP handle instead of GOP data
efi: Fix trailing whitespace in header file
efi/memattr: Convert efi_memattr_init() return type to void
efi: stmm: fix kernel-doc "bad line" warnings
efi/riscv: Remove the useless failure return message print
efistub/x86: Add fallback for SMBIOS record lookup
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 mm updates from Borislav Petkov:
- Use the proper accessors when reading CR3 as part of the page level
transitions (5-level to 4-level, the use case being kexec) so that
only the physical address in CR3 is picked up and not flags which are
above the physical mask shift
- Clean up and unify __phys_addr_symbol() definitions
* tag 'x86_mm_for_v6.19_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
efi/libstub: Fix page table access in 5-level to 4-level paging transition
x86/boot: Fix page table access in 5-level to 4-level paging transition
x86/mm: Unify __phys_addr_symbol()
|
|
Retrieve the GOP device's EDID information in the kernel's boot
parameters. Makes the data avaialble to kernel graphics code and
drives, such as efidrm.
With efidrm, the EDID is now also available to user-space compositors
via standard DRM interfaces.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
Add support for EFI_EDID_DISCOVERED_PROTOCOL and EFI_EDID_ACTIVE_PROTOCOL
as defined in UEFI 2.8, sec 12.9. Define GUIDs and data structures in the
rsp header files.
In the GOP setup function, read the EDID of the primary GOP device. First
try EFI_EDID_ACTIVE_PROTOCOL, which supports user-specified EDID data. Or
else try EFI_EDID_DISCOVERED_PROTOCOL, which returns the display device's
native EDID. If no EDID could be retrieved, clear the storage.
Rename efi_setup_gop() to efi_setup_graphics() to reflect the changes
Let callers pass an optional instance of struct edid_data, if they are
interested.
While screen_info and edid_info come from the same device handle, they
should be considered indendent data. The former refers to the graphics
mode, the latter refers to the display device. GOP devices might not
provide both.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
Move initialization of screen_info into a single helper function.
Frees up space in the main setup helper for adding EDID support.
No functional changes.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
The device handle of the GOP device is required to retrieve the
correct EDID data. Find the handle instead of the GOP data. Still
return the GOP data in the function arguments, as we already looked
it up.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
