Rename pr_efi to efi_info and pr_efi_err to efi_err to make it more
obvious that they are part of the EFI stub and not generic printk infra.
Suggested-by: Joe Perches <joe@perches.com>
Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
Link: https://lore.kernel.org/r/20200430182843.2510180-4-nivedita@alum.mit.edu
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
In several places 64-bit values need to be split up into two 32-bit
fields, in order to be backward-compatible with the old 32-bit ABIs.
Instead of open-coding this, add a helper function to set a 64-bit value
as two 32-bit fields.
Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
Link: https://lore.kernel.org/r/20200430182843.2510180-3-nivedita@alum.mit.edu
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
struct boot_params is only 4096 bytes, not 16384. Fix this by using
sizeof(struct boot_params) instead of hardcoding the incorrect value.
Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
Link: https://lore.kernel.org/r/20200430182843.2510180-2-nivedita@alum.mit.edu
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Commit:
cf6b836648 ("efi/libstub: Make initrd file loader configurable")
inadvertently disabled support on x86 for loading an initrd passed via
the initrd= option on the kernel command line.
Add X86 to the newly introduced Kconfig option's title and depends
declarations, so it gets enabled by default, as before.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: linux-efi@vger.kernel.org
Instead of making match_config_table() test its table_types pointer for
NULL-ness, omit the call entirely if no arch_tables pointer was provided
to efi_config_parse_tables().
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Increase legibility by adding whitespace to the efi_config_table_type_t
arrays that describe which EFI config tables we look for when going over
the firmware provided list. While at it, replace the 'name' char pointer
with a char array, which is more space efficient on relocatable 64-bit
kernels, as it avoids a 8 byte pointer and the associated relocation
data (24 bytes when using RELA format)
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
We no longer need to take special care when using global variables
in the EFI stub, so switch to a simple symbol reference for efi_is64.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
The practice of using __pure getter functions to access global
variables in the EFI stub dates back to the time when we had to
carefully prevent GOT entries from being emitted, because we
could not rely on the toolchain to do this for us.
Today, we use the hidden visibility pragma for all EFI stub source
files, which now all live in the same subdirectory, and we apply a
sanity check on the objects, so we can get rid of these getter
functions and simply refer to global data objects directly.
So switch over the remaining boolean variables carrying options set
on the kernel command line.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
The practice of using __pure getter functions to access global
variables in the EFI stub dates back to the time when we had to
carefully prevent GOT entries from being emitted, because we
could not rely on the toolchain to do this for us.
Today, we use the hidden visibility pragma for all EFI stub source
files, which now all live in the same subdirectory, and we apply a
sanity check on the objects, so we can get rid of these getter
functions and simply refer to global data objects directly.
Start with efi_system_table(), and convert it into a global variable.
While at it, make it a pointer-to-const, because we can.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Now that both arm and x86 are using the linker script to place the EFI
stub's global variables in the correct section, remove __efistub_global.
Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://lore.kernel.org/r/20200416151227.3360778-4-nivedita@alum.mit.edu
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Instead of using __efistub_global to force variables into the .data
section, leave them in the .bss but pull the EFI stub's .bss section
into .data in the linker script for the compressed kernel.
Add relocation checking for x86 as well to catch non-PC-relative
relocations that require runtime processing, since the EFI stub does not
do any runtime relocation processing.
This will catch, for example, data relocations created by static
initializers of pointers.
Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
Link: https://lore.kernel.org/r/20200416151227.3360778-3-nivedita@alum.mit.edu
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Instead of using __efistub_global to force variables into the .data
section, leave them in the .bss but pull the EFI stub's .bss section
into .data in the linker script for the compressed kernel.
Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://lore.kernel.org/r/20200416151227.3360778-2-nivedita@alum.mit.edu
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Move efi_relocate_kernel() into a separate source file, so that it
only gets pulled into builds for architectures that use it. Since
efi_relocate_kernel() is the only user of efi_low_alloc(), let's
move that over as well.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
It is no longer necessary to locate the kernel as low as possible in
physical memory, and so we can switch from efi_low_alloc() [which is
a rather nasty concoction on top of GetMemoryMap()] to a new helper
called efi_allocate_pages_aligned(), which simply rounds up the size
to account for the alignment, and frees the misaligned pages again.
So considering that the kernel can live anywhere in the physical
address space, as long as its alignment requirements are met, let's
switch to efi_allocate_pages_aligned() to allocate the pages.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Break out the code to create an aligned page allocation from mem.c
and move it into a function efi_allocate_pages_aligned() in alignedmem.c.
Update efi_allocate_pages() to invoke it unless the minimum alignment
equals the EFI page size (4 KB), in which case the ordinary page
allocator is sufficient. This way, efi_allocate_pages_aligned() will
only be pulled into the build if it is actually being used (which will
be on arm64 only in the immediate future)
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
The KASLR code path in the arm64 version of the EFI stub incorporates
some overly complicated logic to randomly allocate a region of the right
alignment: there is no need to randomize the placement of the kernel
modulo 2 MiB separately from the placement of the 2 MiB aligned allocation
itself - we can simply follow the same logic used by the non-randomized
placement, which is to allocate at the correct alignment, and only take
TEXT_OFFSET into account if it is not a round multiple of the alignment.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
The notion of a 'preferred' load offset for the kernel dates back to the
times when the kernel's primary mapping overlapped with the linear region,
and memory below it could not be used at all.
Today, the arm64 kernel does not really care where it is loaded in physical
memory, as long as the alignment requirements are met, and so there is no
point in unconditionally moving the kernel to a new location in memory at
boot. Instead, we can
- check for a KASLR seed, and randomly reallocate the kernel if one is
provided
- otherwise, check whether the alignment requirements are met for the
current placement of the kernel, and just run it in place if they are
- finally, do an ordinary page allocation and reallocate the kernel to a
suitably aligned buffer anywhere in memory.
By the same reasoning, there is no need to take TEXT_OFFSET into account
if it is a round multiple of the minimum alignment, which is the usual
case for relocatable kernels with TEXT_OFFSET randomization disabled.
Otherwise, it suffices to use the relative misaligment of TEXT_OFFSET
when reallocating the kernel.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
The implementation of efi_random_alloc() arbitrarily truncates the
provided random seed to 16 bits, which limits the granularity of the
randomly chosen allocation offset in memory. This is currently only
an issue if the size of physical memory exceeds 128 GB, but going
forward, we will reduce the allocation alignment to 64 KB, and this
means we need to increase the granularity to ensure that the random
memory allocations are distributed evenly.
We will need to switch to 64-bit arithmetic for the multiplication,
but this does not result in 64-bit integer intrinsic calls on ARM or
on i386.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
The EFI stub uses a per-architecture #define for the minimum base
and size alignment of page allocations, which is set to 4 KB for
all architecures except arm64, which uses 64 KB, to ensure that
allocations can always be (un)mapped efficiently, regardless of
the page size used by the kernel proper, which could be a kexec'ee
The API wrappers around page based allocations assume that this
alignment is always taken into account, and so efi_free() will
also round up its size argument to EFI_ALLOC_ALIGN.
Currently, efi_random_alloc() does not honour this alignment for
the allocated size, and so freeing such an allocation may result
in unrelated memory to be freed, potentially leading to issues
after boot. So let's round up size in efi_random_alloc() as well.
Fixes: 2ddbfc81ea ("efi: stub: add implementation of efi_random_alloc()")
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Add the ability to automatically pick the highest resolution video mode
(defined as the product of vertical and horizontal resolution) by using
a command-line argument of the form
video=efifb:auto
If there are multiple modes with the highest resolution, pick one with
the highest color depth.
Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
Link: https://lore.kernel.org/r/20200328160601.378299-2-nivedita@alum.mit.edu
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Extend the video mode argument to handle an optional color depth
specification of the form
video=efifb:<xres>x<yres>[-(rgb|bgr|<bpp>)]
Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
Link: https://lore.kernel.org/r/20200320020028.1936003-14-nivedita@alum.mit.edu
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Add the ability to choose a video mode for the selected gop by using a
command-line argument of the form
video=efifb:mode=<n>
Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
Link: https://lore.kernel.org/r/20200320020028.1936003-12-nivedita@alum.mit.edu
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
pixel_format must be one of
PIXEL_RGB_RESERVED_8BIT_PER_COLOR
PIXEL_BGR_RESERVED_8BIT_PER_COLOR
PIXEL_BIT_MASK
since we skip PIXEL_BLT_ONLY when finding a gop.
Remove the redundant code and add another check in find_gop to skip any
pixel formats that we don't know about, in case a later version of the
UEFI spec adds one.
Reformat the code a little.
Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
Link: https://lore.kernel.org/r/20200320020028.1936003-10-nivedita@alum.mit.edu
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Use the __ffs/__fls macros to calculate the position and size of the
mask.
Correct type of mask to u32 instead of unsigned long.
Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
Link: https://lore.kernel.org/r/20200320020028.1936003-9-nivedita@alum.mit.edu
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Move extraction of the mode information parameters outside the loop to
find the gop, and eliminate some redundant variables.
Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
Link: https://lore.kernel.org/r/20200320020028.1936003-4-nivedita@alum.mit.edu
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Fix the following sparse warning:
drivers/firmware/efi/libstub/arm-stub.c:68:6: warning:
symbol 'install_memreserve_table' was not declared. Should it be static?
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Zou Wei <zou_wei@huawei.com>
Link: https://lore.kernel.org/r/1587643713-28169-1-git-send-email-zou_wei@huawei.com
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
We have wrappers around EFI calls so that x86 can define special
versions for mixed mode, while all other architectures can use the
same simple definition that just issues the call directly.
In preparation for the arrival of yet another architecture that doesn't
need anything special here (RISC-V), let's move the default definition
into a shared header.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Loading an initrd passed via the kernel command line is deprecated: it
is limited to files that reside in the same volume as the one the kernel
itself was loaded from, and we have more flexible ways to achieve the
same. So make it configurable so new architectures can decide not to
enable it.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Most of the arm-stub code is written in an architecture independent manner.
As a result, RISC-V can reuse most of the arm-stub code.
Rename the arm-stub.c to efi-stub.c so that ARM, ARM64 and RISC-V can use it.
This patch doesn't introduce any functional changes.
Signed-off-by: Atish Patra <atish.patra@wdc.com>
Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com>
Link: https://lore.kernel.org/r/20200415195422.19866-2-atish.patra@wdc.com
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Arnd reports that commit
9302c1bb8e ("efi/libstub: Rewrite file I/O routine")
reworks the file I/O routines in a way that triggers the following
warning:
drivers/firmware/efi/libstub/file.c:240:1: warning: the frame size
of 1200 bytes is larger than 1024 bytes [-Wframe-larger-than=]
We can work around this issue dropping an instance of efi_char16_t[256]
from the stack frame, and reusing the 'filename' field of the file info
struct that we use to obtain file information from EFI (which contains
the file name even though we already know it since we used it to open
the file in the first place)
Reported-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20200409130434.6736-8-ardb@kernel.org
Commit
d5cdf4cfea ("efi/x86: Don't relocate the kernel unless necessary")
tries to avoid relocating the kernel in the EFI stub as far as possible.
However, when systemd-boot is used to boot a unified kernel image [1],
the image is constructed by embedding the bzImage as a .linux section in
a PE executable that contains a small stub loader from systemd that will
call the EFI stub handover entry, together with additional sections and
potentially an initrd. When this image is constructed, by for example
dracut, the initrd is placed after the bzImage without ensuring that at
least init_size bytes are available for the bzImage. If the kernel is
not relocated by the EFI stub, this could result in the compressed
kernel's startup code in head_{32,64}.S overwriting the initrd.
To prevent this, unconditionally relocate the kernel if the EFI stub was
entered via the handover entry point.
[1] https://systemd.io/BOOT_LOADER_SPECIFICATION/#type-2-efi-unified-kernel-images
Fixes: d5cdf4cfea ("efi/x86: Don't relocate the kernel unless necessary")
Reported-by: Sergey Shatunov <me@prok.pw>
Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20200406180614.429454-2-nivedita@alum.mit.edu
Link: https://lore.kernel.org/r/20200409130434.6736-5-ardb@kernel.org
Commit
3ee372ccce ("x86/boot/compressed/64: Remove .bss/.pgtable from bzImage")
removed the .bss section from the bzImage.
However, while a PE loader is required to zero-initialize the .bss
section before calling the PE entry point, the EFI handover protocol
does not currently document any requirement that .bss be initialized by
the bootloader prior to calling the handover entry.
When systemd-boot is used to boot a unified kernel image [1], the image
is constructed by embedding the bzImage as a .linux section in a PE
executable that contains a small stub loader from systemd together with
additional sections and potentially an initrd. As the .bss section
within the bzImage is no longer explicitly present as part of the file,
it is not initialized before calling the EFI handover entry.
Furthermore, as the size of the embedded .linux section is only the size
of the bzImage file itself, the .bss section's memory may not even have
been allocated.
In particular, this can result in efi_disable_pci_dma being true even
when it was not specified via the command line or configuration option,
which in turn causes crashes while booting on some systems.
To avoid issues, place all EFI stub global variables into the .data
section instead of .bss. As of this writing, only boolean flags for a
few command line arguments and the sys_table pointer were in .bss and
will now move into the .data section.
[1] https://systemd.io/BOOT_LOADER_SPECIFICATION/#type-2-efi-unified-kernel-images
Fixes: 3ee372ccce ("x86/boot/compressed/64: Remove .bss/.pgtable from bzImage")
Reported-by: Sergey Shatunov <me@prok.pw>
Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20200406180614.429454-1-nivedita@alum.mit.edu
Link: https://lore.kernel.org/r/20200409130434.6736-4-ardb@kernel.org
A collection of small fixes gathered since the previous update.
* ALSA core:
- Regression fix for OSS PCM emulation
* ASoC:
- Trivial fixes in reg bit mask ops, DAPM, DPCM and topology
- Lots of fixes for Intel-based devices
- Minor fixes for AMD, STM32, Qualcomm, Realtek
* Others
- Fixes for the bugs in mixer handling in HD-audio and ice1724
drivers that were caught by the recent kctl validator
- New quirks for HD-audio and USB-audio
Also this contains a fix for EDD firmware fix, which slipped
from anyone's hands.
-----BEGIN PGP SIGNATURE-----
iQJCBAABCAAsFiEEIXTw5fNLNI7mMiVaLtJE4w1nLE8FAl6PLNAOHHRpd2FpQHN1
c2UuZGUACgkQLtJE4w1nLE9Dww//S7LOszzp3CczyVzNzR6XHGArnpWHmQrol+ab
cwL+Vs30vnlvLTnbyER6q5DeGpBhMfQozp8Ac/LeTd0g3hdh4pIOT2K7oF4MWrk8
rVlZXI/Q8fKRC5jQR1MedA+naH+1JRKnY7+WqjKlUoDDJaZTygCFADHY4OMtfa7a
n93d1cAbiUMF+q8CAnxHsNcs6/7rUQiY7HcKrUcNyj8BNaWhWYffMhA8cY6S+8Q7
9fnjOOc/m5Wy3xTnXHeHlaaqRri8y9t21wXX4vPQZtPPqZ280qqlGcl2nGH4rAVn
Hl8I6W7Z/fFZao6oZPf8bBDGFiBjb3/6Q8593xB+m85xqfepgbqP0vHDpqOU5hUR
2rYZIrJOrlYPslIyujhNtCw4OTy6OqbHoZ5iWe0JMXH6u0Ht/XwVx3GCHaupe9gG
km7FsHfjDw9kkfwImIE7qJTvvTt9l8EZbeCR4zAn204kJkkumlogMYIlcYO2noN4
dItCeeF7iMhUlgFehsbLw9MEz1bHxMsjKedF97hAlKXwKoz2tM00du84pEs3JaGX
BCcUke/smVeFUOV8hLOZx1G2e9kR/dHESOOp/1pGJgvNlbboXSyoZNyk9zIlvntx
uLGon2qYAVXwEmfqQkSAwc/dxuyaYYZVhlXNBQXX6hQC+zw1e9yYddnpY+HX/1r0
6qDJW4k=
=mFJY
-----END PGP SIGNATURE-----
Merge tag 'sound-fix-5.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"A collection of small fixes gathered since the previous update.
ALSA core:
- Regression fix for OSS PCM emulation
ASoC:
- Trivial fixes in reg bit mask ops, DAPM, DPCM and topology
- Lots of fixes for Intel-based devices
- Minor fixes for AMD, STM32, Qualcomm, Realtek
Others:
- Fixes for the bugs in mixer handling in HD-audio and ice1724
drivers that were caught by the recent kctl validator
- New quirks for HD-audio and USB-audio
Also this contains a fix for EDD firmware fix, which slipped from
anyone's hands"
* tag 'sound-fix-5.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (35 commits)
ALSA: hda: Add driver blacklist
ALSA: usb-audio: Add mixer workaround for TRX40 and co
ALSA: hda/realtek - Add quirk for MSI GL63
ALSA: ice1724: Fix invalid access for enumerated ctl items
ALSA: hda: Fix potential access overflow in beep helper
ASoC: cs4270: pull reset GPIO low then high
ALSA: hda/realtek - Add HP new mute led supported for ALC236
ALSA: hda/realtek - Add supported new mute Led for HP
ASoC: rt5645: Add platform-data for Medion E1239T
ASoC: Intel: bytcr_rt5640: Add quirk for MPMAN MPWIN895CL tablet
ASoC: stm32: sai: Add missing cleanup
ALSA: usb-audio: Add registration quirk for Kingston HyperX Cloud Alpha S
ASoC: Intel: atom: Fix uninitialized variable compiler warning
ASoC: Intel: atom: Check drv->lock is locked in sst_fill_and_send_cmd_unlocked
ASoC: Intel: atom: Take the drv->lock mutex before calling sst_send_slot_map()
ASoC: SOF: Turn "firmware boot complete" message into a dbg message
ALSA: usb-audio: Add Pioneer DJ DJM-250MK2 quirk
ALSA: pcm: oss: Fix regression by buffer overflow fix (again)
ALSA: pcm: oss: Fix regression by buffer overflow fix
edd: Use scnprintf() for avoiding potential buffer overflow
...
- Ensure that the compiler and linker versions are aligned so that ld
doesn't complain about not understanding a .note.gnu.property section
(emitted when pointer authentication is enabled).
- Force -mbranch-protection=none when the feature is not enabled, in
case a compiler may choose a different default value.
- Remove CONFIG_DEBUG_ALIGN_RODATA. It was never in defconfig and rarely
enabled.
- Fix checking 16-bit Thumb-2 instructions checking mask in the
emulation of the SETEND instruction (it could match the bottom half of
a 32-bit Thumb-2 instruction).
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEE5RElWfyWxS+3PLO2a9axLQDIXvEFAl6PUYAACgkQa9axLQDI
XvH83g/7B5v0RFqjqVW4/cQKoN1rii7qSA8pBfNgGiCMJKtoGvliAlp3xWEtlW0h
nYJ4gCvey946r5kvZrjdBXC/Ulo2CcGYtX0n8d+8IB6wXAnGcQ0DUBUFZ4+fAU9Z
F7+R7its24dma9R1wIFHFmQUdlO+EgQTfQFvhQKYMSNVaFQF73Sp/vk3oKhJ2E0x
QevgDBQSmmcX3DFxhUW7BdcdboBgtTDUGdhcImdorgp7QmI1r40espJKX4VMKvmb
pfzwg+i7KM6N1RDhRfA2oFMegXwI3rvM3XesqYaua8+xWD5vJuIQfq+ysEq9F9x/
Hnu+W9nbcN8RKQ9JToiqkE7ifuOBTvaIJaqsgIXYSqtYjatuPAh85MkrorHi9Ji2
9i7fc0GMTgtgYDo/93++l8SmmRJMX+h+9KtGtxx39+UqGjToJMCnPGjwBSwe4wdK
lKOAgj488HHsNwTlrRUnq1hXjNjd1w+ON7JM2L3IyRNX/eWN60VxwzwHkZMByCOj
jlcY4ISWquigW4w9Sp4nxEhLF9dWT1+OrE33Xh3CUxPU94jSEvgcDHcxuGeGOlrA
QjN1B2APZFox8XbOsLgeG2kKe5C3Fui90SEn0GyA0ncVLsXDI78VnVJR9uz5+6Pd
ALVQKkJxswhSDPQFlH+7CmQAcr8jWyLEEvyXXaZsoJmewzCpEPM=
=pHRG
-----END PGP SIGNATURE-----
Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
Pull arm64 fixes from Catalin Marinas:
- Ensure that the compiler and linker versions are aligned so that ld
doesn't complain about not understanding a .note.gnu.property section
(emitted when pointer authentication is enabled).
- Force -mbranch-protection=none when the feature is not enabled, in
case a compiler may choose a different default value.
- Remove CONFIG_DEBUG_ALIGN_RODATA. It was never in defconfig and
rarely enabled.
- Fix checking 16-bit Thumb-2 instructions checking mask in the
emulation of the SETEND instruction (it could match the bottom half
of a 32-bit Thumb-2 instruction).
* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
arm64: armv8_deprecated: Fix undef_hook mask for thumb setend
arm64: remove CONFIG_DEBUG_ALIGN_RODATA feature
arm64: Always force a branch protection mode when the compiler has one
arm64: Kconfig: ptrauth: Add binutils version check to fix mismatch
init/kconfig: Add LD_VERSION Kconfig
These are the usual updates for SoC specific device drivers and related
subsystems that don't have their own top-level maintainers:
- ARM SCMI/SCPI updates to allow pluggable transport layers
- TEE subsystem cleanups
- A new driver for the Amlogic secure power domain controller
- Various driver updates for the NXP Layerscape DPAA2, NXP i.MX SCU and
TI OMAP2+ sysc drivers.
- Qualcomm SoC driver updates, including a new library module for
"protection domain" notifications
- Lots of smaller bugfixes and cleanups in other drivers
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAl6EaKsACgkQmmx57+YA
GNng5RAAnSi3jLBG3PsX4XCydurlhbYDnakzp2x7kNi0aeN0mR7YT6nbmm8Iax0A
tYpUNt6mhsSnE7thAX6kIm1CIPw7oKzg5tz9TaNRJT6q1i0+MA0bWAX0KOVzruj5
xllUIoV0WsYHRjqjxWOJht7zYKTX5PoKr3weRVqHYR60hjkNFT4Myx3HpXn5nQ46
sEgic+S8WCsbffPqs5HUqkNx9R6D7RIJ72BFSF7o1wy2Brj+g0BxfxAjty+kaWwT
LtsJm0naGGRag17iij7wBnZ+odWNi80qhtthUncx/c5s517J8Z7Nq2QZJa7XhhjV
9+/1av7wKyE+V54wnCP4ACZjyE+xE3ghzVxOuzjZfbhkmNCELAx2jmQJbt9gr/t4
Uek8iANq3bo0epy4iJglfeEJuZ8rZal3oC1gU5rCun/VsqPe5OWhFCzvhu7zVgnD
Npk/IhCrp7117v5DG2Pvhd9YxigZ4ju3NW2gWukh0TemejRIzyoZyNWux+JD/jCn
V3ANtT4aCqTJ3ZOL7IaDcX5Kze4KmZZvNKvSSCndcen7u95Z8eW9sIKkSrlp3P5f
cZAdyULX22im6jXzNz4DJYFRrYgRdXfRLyrS555rGoYZGB1FB1Jhl7SUr385XpBZ
XD18oPIPm0C3Dn/nhbKC8K44tpKazET8aMCg5lO4bzI5EwqingI=
=qbsP
-----END PGP SIGNATURE-----
Merge tag 'arm-drivers-5.7' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
Pull ARM driver updates from Arnd Bergmann:
"These are the usual updates for SoC specific device drivers and
related subsystems that don't have their own top-level maintainers:
- ARM SCMI/SCPI updates to allow pluggable transport layers
- TEE subsystem cleanups
- A new driver for the Amlogic secure power domain controller
- Various driver updates for the NXP Layerscape DPAA2, NXP i.MX SCU
and TI OMAP2+ sysc drivers.
- Qualcomm SoC driver updates, including a new library module for
"protection domain" notifications
- Lots of smaller bugfixes and cleanups in other drivers"
* tag 'arm-drivers-5.7' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (70 commits)
soc: fsl: qe: fix sparse warnings for ucc_slow.c
soc: fsl: qe: ucc_slow: remove 0 assignment for kzalloc'ed structure
soc: fsl: qe: fix sparse warnings for ucc_fast.c
soc: fsl: qe: fix sparse warnings for qe_ic.c
soc: fsl: qe: fix sparse warnings for ucc.c
soc: fsl: qe: fix sparse warning for qe_common.c
soc: fsl: qe: fix sparse warnings for qe.c
soc: qcom: Fix QCOM_APR dependencies
soc: qcom: pdr: Avoid uninitialized use of found in pdr_indication_cb
soc: imx: drop COMPILE_TEST for IMX_SCU_SOC
firmware: imx: add COMPILE_TEST for IMX_SCU driver
soc: imx: gpc: fix power up sequencing
soc: imx: increase build coverage for imx8m soc driver
soc: qcom: apr: Add avs/audio tracking functionality
dt-bindings: soc: qcom: apr: Add protection domain bindings
soc: qcom: Introduce Protection Domain Restart helpers
devicetree: bindings: firmware: add ipq806x to qcom_scm
memory: tegra: Correct debugfs clk rate-range on Tegra124
memory: tegra: Correct debugfs clk rate-range on Tegra30
memory: tegra: Correct debugfs clk rate-range on Tegra20
...
