linux-next.git/arch/arm/include/uapi, branch master

init, arch: make CONFIG_COMMAND_LINE_SIZE globally configurable

2026-09-04T00:39:49+00:00

Currently, s390 has the ability to configure the maximum kernel command line size via Kconfig (CONFIG_COMMAND_LINE_SIZE). Other architectures define a hardcoded COMMAND_LINE_SIZE macro in their setup.h headers. In some use cases, such as netboot kernels, rootfs configurations, or larger initramfs setups, a larger command line size is required. While for embedded workloads, it can be reduced to save memory. Move CONFIG_COMMAND_LINE_SIZE out of arch/s390/Kconfig and into init/Kconfig under General setup, and update every architecture's setup.h header to define COMMAND_LINE_SIZE as CONFIG_COMMAND_LINE_SIZE. For user-space API (uapi) headers, wrap the definition in an `#ifdef __KERNEL__` guard and retain the historical hardcoded default in the `#else` block. When user-space headers are installed via `make headers_install`, unifdef strips out the kernel section, ensuring the same value as before for user-space applications including ``. For S390, the range is kept the same, but other architectures have varying constraints. S390 requires a minimum of 896 bytes to protect legacy bootloaders from overwriting the .text section. ARM, M68K, and NIOS2 allocate the command line directly on severely constrained decompressor stacks, so their ranges are strictly capped at 2048 bytes to prevent deterministic stack exhaustion and boot panics. PowerPC (PPC) boot wrappers silently truncate arguments past 2048 bytes, so it is also capped at 2048 to prevent silent parameter loss. The SuperH (SUPERH) boot parameter page allocates exactly PAGE_SIZE (typically 4096 bytes), and placing a 4096-byte command line starting at offset 256 would cause strscpy() to read out of bounds; it is capped at 3840 bytes. Alpha physically limits its boot parameter block to 256 bytes, so its limit is strictly locked to 256. All other architectures are capped at 4096 bytes to prevent unreasonable allocations. Link: https://lore.kernel.org/20260818231646.804507-2-wfelipe@google.com Signed-off-by: Maciej Żenczykowski Signed-off-by: Wilson Felipe Pereira Cc: Albert Ou Cc: Alexander Gordeev Cc: Alexandre Ghiti Cc: Arnd Bergmann Cc: Christian Borntraeger Cc: Heiko Carstens Cc: Palmer Dabbelt Cc: Sven Schnelle Cc: Vasily Gorbik Signed-off-by: Andrew Morton

vfs: uapi: retire octal and hex numbers in favor of (1 << n) for O_ flags

2026-06-06T13:34:03+00:00

A recent build failure[1] exposed the diffculty of working with the current octal and hex definitions of O_ flags when trying to find a gap for a new flag. This difficulty is compounded by the fact that O_ flags may have architectural specific values. Replace the hex/octal #defines, which are hard to parse when looking for free bits, with explicit bit shifts like (1 << 11). Also, add comments that identify which architectures redefine some of the seemingly free ("cursed") bits in uapi/asm-generic/fcntl.h. These should not be used to define new O_ flags (for now, at least). The translastion was done with Claude Opus 4.8, and verified with a (non-AI) gawk script. The accounting of which architectures claim which bit-gaps in uapi/asm-generic/fcntl.h is also done by hand. [1]: https://lore.kernel.org/all/agruPPybCx8q2XcJ@sirena.org.uk/ Assisted-by: Claude:Opus 4.8 Signed-off-by: Jori Koolstra Link: https://patch.msgid.link/20260604222405.5382-1-jkoolstra@xs4all.nl Signed-off-by: Christian Brauner (Amutable)

ARM: uapi: Drop PSR_ENDSTATE

2026-01-30T15:46:17+00:00

The symbol PSR_ENDSTATE is pointless for userspace. Drop it from the UAPI headers and instead inline it into the only two callers. As as side-effect, remove a leak of an internal kconfig symbol through the UAPI headers. Suggested-by: Arnd Bergmann Link: https://lore.kernel.org/lkml/d2ad12f2-3d65-4bef-890c-65d78a33d790@app.fastmail.com/ Signed-off-by: Thomas Weißschuh Signed-off-by: Arnd Bergmann

arm: update in-source documentation references

2023-06-12T12:33:48+00:00

The Arm documentation has moved to Documentation/arch/arm; update references within arch/arm to match. Cc: Russell King Cc: Alim Akhtar Cc: Patrice Chotard Cc: linux-doc@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-arch@vger.kernel.org Signed-off-by: Jonathan Corbet

ARM: 9274/1: Add hwcap for Speculative Store Bypassing Safe

2022-11-28T11:57:35+00:00

Speculative Store Bypassing Safe(FEAT_SSBS) is a feature present in AArch32 state for Armv8 and is represented by ID_PFR2_EL1.SSBS identification register. This feature denotes the presence of PSTATE.ssbs bit and hence adding a hwcap will enable the userspace to check it before trying to set/unset this PSTATE. This commit adds the ID feature bit detection, and uses elf_hwcap2 accordingly. Reviewed-by: Linus Walleij Signed-off-by: Amit Daniel Kachhap Signed-off-by: Russell King (Oracle)

ARM: 9273/1: Add hwcap for Speculation Barrier(SB)

2022-11-28T11:57:35+00:00

Speculation Barrier(FEAT_SB) is a feature present in AArch32 state for Armv8 and is represented by ISAR6.SB identification register. This feature denotes the presence of SB instruction and hence adding a hwcap will enable the userspace to check it before trying to use this instruction. This commit adds the ID feature bit detection, and uses elf_hwcap2 accordingly. Reviewed-by: Linus Walleij Signed-off-by: Amit Daniel Kachhap Signed-off-by: Russell King (Oracle)

ARM: 9272/1: vfp: Add hwcap for FEAT_AA32I8MM

2022-11-28T11:57:34+00:00

Int8 matrix multiplication (FEAT_AA32I8MM) is a feature present in AArch32 state for Armv8 and is represented by ISAR6.I8MM identification register. This feature denotes the presence of VSMMLA, VSUDOT, VUMMLA, VUSMMLA and VUSDOT instructions and hence adding a hwcap will enable the userspace to check it before trying to use those instructions. Reviewed-by: Linus Walleij Signed-off-by: Amit Daniel Kachhap Signed-off-by: Russell King (Oracle)

ARM: 9271/1: vfp: Add hwcap for FEAT_AA32BF16

2022-11-28T11:57:33+00:00

Advanced SIMD BFloat16 (FEAT_AA32BF16) is a feature present in AArch32 state for Armv8 and is represented by ISAR6.BF16 identification register. This feature denotes the presence of VCVT, VCVTB, VCVTT, VDOT, VFMAB, VFMAT and VMMLA instructions and hence adding a hwcap will enable the userspace to check it before trying to use those instructions. Reviewed-by: Linus Walleij Signed-off-by: Amit Daniel Kachhap Signed-off-by: Russell King (Oracle)

ARM: 9270/1: vfp: Add hwcap for FEAT_FHM

2022-11-28T11:57:33+00:00

Floating-point half-precision multiplication (FHM) is a feature present in AArch32 state for Armv8 and is represented by ISAR6.FHM identification register. This feature denotes the presence of VFMAL and VMFSL instructions and hence adding a hwcap will enable the userspace to check it before trying to use those instructions. Reviewed-by: Linus Walleij Signed-off-by: Amit Daniel Kachhap Signed-off-by: Russell King (Oracle)

ARM: 9269/1: vfp: Add hwcap for FEAT_DotProd

2022-11-28T11:57:32+00:00

Advanced Dot product is a feature present in AArch32 state for Armv8 and is represented by ISAR6 identification register. This feature denotes the presence of UDOT and SDOT instructions and hence adding a hwcap will enable the userspace to check it before trying to use those instructions. Reviewed-by: Linus Walleij Signed-off-by: Amit Daniel Kachhap Signed-off-by: Russell King (Oracle)