linux-stable.git/arch/sh/kernel, branch master

Merge tag 'gpio-updates-for-v7.3-rc1-v2' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux

2026-08-19T16:10:07+00:00

Pull gpio updates from Bartosz Golaszewski:
 "GPIO core:
   - extend the gpio-regmap abstraction layer with more features
     allowing users to override configuration setting, translate
     register values and masks and enable/disable interrupts
   - extend GPIO kunit tests with suites verifying probe ordering by
     software node devlink support and software node hogs
   - shrink GPIO kunit initialization code
   - coding style updates (remove commas from sentinels where
     applicable)
   - with all users now converted treewide to using real firmware node
     links for software node GPIO lookup: remove the deprecated
     label-matching mechanism from from GPIO core
   - drop redundant return value check of nonseekable_open() in
     gpiolib-cdev
   - use IRQ trigger helpers where applicable

  Driver updates:
   - refactor error paths and logging in gpio-nomadik
   - use more modern interfaces for getting resources in gpio-rockchip,
     gpio-bt8xx and gpio-pca9570
   - add missing MODULE_DEVICE_TABLE() to gpio-sifive and gpio-vf610
   - drop unused FILONOFF macro from gpio-rcar
   - extend build coverage of ioport GPIO drivers with COMPILE_TEST=y
   - only enable the gpio-rtd driver by default with ARCH_REALTEK=y to
     avoid bloating the build
   - refactor coding style in several drivers
   - use correct endianess translation in gpio-pcf85x
   - add wake-up interrupt support to gpio-mvebu
   - apply initial value in direction output setter in gpio-by-pinctrl

  Misc:
   - replace linux/gpio.h inclusions treewide with linux/gpio/legacy.h
     which now exports all the deprecated APIs
   - select GPIOLIB_LEGACY in Kconfig where required treewide
   - use software nodes for gpio-keys in MFD drivers

  Devicetree bindings:
   - describe the realtek rtd1625 GPIO controller
   - document new models for gpio-pca95xx and gpio-cadence
   - document new property in gpio-rockchip"

* tag 'gpio-updates-for-v7.3-rc1-v2' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux: (61 commits)
  gpio: gpio-by-pinctrl: Apply initial value in direction output wrapper
  dt-bindings: gpio: rockchip,gpio-bank: Add rockchip,grf property
  gpio: Use IRQ trigger mask helpers
  gpio: allow COMPILE_TEST for IOPORT drivers
  gpio: realtek: Add driver for Realtek DHC RTD1625 SoC
  gpio: regmap: Add IRQ enable/disable helpers
  gpio: regmap: Add set_config callback
  gpio: regmap: Add value_xlate callback
  gpio: regmap: Add gpio_regmap_operation to extend reg_mask_xlate callback
  gpio: regmap: Order kernel-doc descriptions with the actual appearance
  gpio: regmap: Apply default resource callbacks for regmap IRQ chip
  gpio: regmap: Provide default IRQ resource request and release callbacks
  Revert "gpio: realtek: Add driver for Realtek DHC RTD1625 SoC"
  gpib: gpio: replace linux/gpio.h inclusion
  Input: matrix_keyboard - replace linux/gpio.h inclusion
  phy: replace linux/gpio.h inclusions
  pcmcia: replace linux/gpio.h inclusions
  ASoC: replace linux/gpio.h inclusions
  mfd: replace linux/gpio.h inclusions
  sh: replace linux/gpio.h inclusions
  ...

Merge tag 'core-entry-2026-08-17' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2026-08-18T22:00:56+00:00

Pull generic entry code updates from Thomas Gleixner:

 - Make syscall user dispatching configurable

   Not all architectures can makes use of syscall user dispatching.
   Allow them to disable the feature completely.

 - Consolidate stack randomization for the generic entry code and the
   architectures using it.

   Stack randomization on syscall entry was sprinkled throughout the
   architecture specific low level entry code and in some cases at the
   wrong points, e.g. before establishing state, which violates the
   non-instrumentable constraints of that code.

   Clean this up by integrating stack randomization into the generic
   entry code helpers so that it is invoked at the earliest possible
   point right after establishing state and converting all generic entry
   code using architecture over.

 - Clean up the syscall number handling in the generic entry code. It
   works correctly for architectures which have a separate return value
   storage in pt_regs, but fails to distinguish the case where user
   space handed in -1 as syscall number from the case where the entry
   code rejects it by returning -1 to the callers. Aside of that the
   return value functionality of those interfaces is not really
   intuitive.

   Fix this by separating the decision to reject a syscall (user
   dispatch, ptrace, seccomp ...) from the potential modification of the
   syscall number through these mechanisms.

   This solves most of the problems for architectures which do not have
   a separate return value storage in pt_regs except for the case where
   a tracepoint has a BPF script or a probe attached which overwrite
   both the syscall number and the return value. But that's a problem
   which cannot be solved in the generic code, that only can be
   addressed by separating the storage model in the affected
   architectures.

* tag 'core-entry-2026-08-17' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (23 commits)
  entry, treewide: Make syscall_enter_from_user_mode[_work]() indicate syscall execution
  entry: Make return type of syscall_trace_enter() bool
  entry: Rework trace_syscall_enter()
  entry: Rework syscall_audit_enter()
  syscall_user_dispatch: Introduce ARCH_SUPPORTS_SYSCALL_USER_DISPATCH
  entry: Fix seccomp bypass after ptrace with TSYNC
  x86/entry: Simplify the syscall number logic
  x86/entry: Get rid of the sys_ni_syscall() indirection
  x86/entry: Make syscall functions static
  ptrace, treewide: Rename ptrace_report_syscall_entry() to ptrace_report_syscall_permit_entry()
  seccomp, treewide: Rename and convert __secure_computing() to return boolean
  entry: Use syscall number instead of rereading it
  entry: Remove syscall_enter_from_user_mode()
  x86/syscall: Use [syscall_]enter_from_user_mode_randomize_stack()
  s390/syscall: Use enter_from_user_mode_randomize_stack()
  riscv/syscall: Use syscall_enter_from_user_mode_randomize_stack()
  powerpc/syscall: Use syscall_enter_from_user_mode_randomize_stack()
  loongarch/syscall: Use syscall_enter_from_user_mode_randomize_stack()
  entry: Provide [syscall_]enter_from_user_mode_randomize_stack()
  randomize_kstack: Provide add_random_kstack_offset_irqsoff()
  ...

arch: hookup fchroot() system call

2026-07-27T15:18:00+00:00

Wire up the fchroot() system call as number 472 on (nearly) all
architectures and sync the mirrored copies of the syscall tables and
the asm-generic unistd.h under tools/.

Link: https://patch.msgid.link/20260724-work-failfs-v2-5-485dabbae185@kernel.org
Signed-off-by: Christian Brauner (Amutable)

sh: replace linux/gpio.h inclusions

2026-07-24T18:12:48+00:00

linux/gpio.h should no longer be used, convert these instead to
linux/gpio/legacy.h for the sh boards using the legacy interfaces,
or remove it where it is not needed at all.

Acked-by: Bartosz Golaszewski 
Reviewed-by: Linus Walleij 
Signed-off-by: Arnd Bergmann

ptrace, treewide: Rename ptrace_report_syscall_entry() to ptrace_report_syscall_permit_entry()

2026-07-12T10:38:02+00:00

The return value of that function is boolean and tells the caller whether
to permit the syscall processing or not.

Rename the function so the purpose is clear and make the return type bool.

Signed-off-by: Thomas Gleixner 
Tested-by: Mukesh Kumar Chaurasiya (IBM) 
Reviewed-by: Jinjie Ruan 
Reviewed-by: Radu Rendec 
Reviewed-by: Mukesh Kumar Chaurasiya (IBM) 
Acked-by: Oleg Nesterov 
Acked-by: Magnus Lindholm 
Link: https://patch.msgid.link/20260707190254.280015701@kernel.org

seccomp, treewide: Rename and convert __secure_computing() to return boolean

2026-07-12T10:38:02+00:00

The return value of __secure_computing() currently uses 0 to indicate
that a system call should be allowed, and -1 to indicate that it should
be blocked/killed. This 0/-1 pattern is non-intuitive for a security
check function and makes the control flow at the call sites less readable.

Furthermore, any potential future changes to these return values would
require a high-risk, error-prone audit of all its users across different
architectures.

Sanitize this logic by converting the return type of __secure_computing()
to a proper boolean, where 'true' explicitly means 'allow' and 'false'
means 'fail/deny'.

Update all the two dozen or so call sites across the tree to align with
this new boolean semantic. No functional changes are intended, as the
callers still return -1 to the lower-level assembly entry code upon
seccomp denial.

Rename the function to __seccomp_permit_syscall() so that the purpose is
entirely clear.

[ tglx: Rename the function ]

Suggested-by: Thomas Gleixner 
Suggested-by: Mark Rutland 
Signed-off-by: Jinjie Ruan 
Signed-off-by: Thomas Gleixner 
Tested-by: Mukesh Kumar Chaurasiya (IBM) 
Reviewed-by: Mukesh Kumar Chaurasiya (IBM) 
Acked-by: Oleg Nesterov 
Link: https://patch.msgid.link/20260707190254.230735780@kernel.org

genirq/proc: Increase default interrupt number precision to four

2026-05-26T14:21:14+00:00

Quite some architectures have four character wide acronyms for architecture
specific interrupts like IPI, NMI, etc.

The default precision of printing the Linux device interrupt numbers is
three, which causes quite some code to play games with adding or omitting
space after the acronym and the colon in order to keep the per CPU numbers
properly aligned.

Increase the default number precision to four in the core code and get rid
of the space games all over the place. At the same time align all
architecture specific descriptor texts left so that they show up in the
same column as the interrupt chip names, which makes the output more
uniform accross architectures. Fix up the GDB script to this new scheme as
well.

Signed-off-by: Thomas Gleixner 
Link: https://patch.msgid.link/20260517194931.839482411@kernel.org

arch, mm: consolidate empty_zero_page

2026-04-05T20:53:01+00:00

Reduce 22 declarations of empty_zero_page to 3 and 23 declarations of
ZERO_PAGE() to 4.

Every architecture defines empty_zero_page that way or another, but for the
most of them it is always a page aligned page in BSS and most definitions
of ZERO_PAGE do virt_to_page(empty_zero_page).

Move Linus vetted x86 definition of empty_zero_page and ZERO_PAGE() to the
core MM and drop these definitions in architectures that do not implement
colored zero page (MIPS and s390).

ZERO_PAGE() remains a macro because turning it to a wrapper for a static
inline causes severe pain in header dependencies.

For the most part the change is mechanical, with these being noteworthy:

* alpha: aliased empty_zero_page with ZERO_PGE that was also used for boot
  parameters. Switching to a generic empty_zero_page removes the aliasing
  and keeps ZERO_PGE for boot parameters only
* arm64: uses __pa_symbol() in ZERO_PAGE() so that definition of
  ZERO_PAGE() is kept intact.
* m68k/parisc/um: allocated empty_zero_page from memblock,
  although they do not support zero page coloring and having it in BSS
  will work fine.
* sparc64 can have empty_zero_page in BSS rather allocate it, but it
  can't use virt_to_page() for BSS. Keep it's definition of ZERO_PAGE()
  but instead of allocating it, make mem_map_zero point to
  empty_zero_page.
* sh: used empty_zero_page for boot parameters at the very early boot.
  Rename the parameters page to boot_params_page and let sh use the generic
  empty_zero_page.
* hexagon: had an amusing comment about empty_zero_page

	/* A handy thing to have if one has the RAM. Declared in head.S */

  that unfortunately had to go :)

Link: https://lkml.kernel.org/r/20260211103141.3215197-4-rppt@kernel.org
Signed-off-by: Mike Rapoport (Microsoft) 
Acked-by: Helge Deller 		[parisc]
Tested-by: Helge Deller 		[parisc]
Reviewed-by: Christophe Leroy (CS GROUP) 
Acked-by: Dave Hansen 
Acked-by: Catalin Marinas 
Acked-by: Magnus Lindholm 	[alpha]
Acked-by: Dinh Nguyen 	[nios2]
Acked-by: Andreas Larsson 	[sparc]
Acked-by: David Hildenbrand (Arm) 
Acked-by: Liam R. Howlett 
Cc: "Borislav Petkov (AMD)" 
Cc: David S. Miller 
Cc: Geert Uytterhoeven 
Cc: Guo Ren 
Cc: Huacai Chen 
Cc: Ingo Molnar 
Cc: Johannes Berg 
Cc: John Paul Adrian Glaubitz 
Cc: Lorenzo Stoakes 
Cc: Madhavan Srinivasan 
Cc: Matt Turner 
Cc: Max Filippov 
Cc: Michael Ellerman 
Cc: Michal Hocko 
Cc: Michal Simek 
Cc: Palmer Dabbelt 
Cc: Richard Weinberger 
Cc: Russell King 
Cc: Stafford Horne 
Cc: Suren Baghdasaryan 
Cc: Vineet Gupta 
Cc: Vlastimil Babka 
Cc: Will Deacon 
Signed-off-by: Andrew Morton

kbuild: Split .modinfo out from ELF_DETAILS

2026-02-26T18:50:19+00:00

Commit 3e86e4d74c04 ("kbuild: keep .modinfo section in
vmlinux.unstripped") added .modinfo to ELF_DETAILS while removing it
from COMMON_DISCARDS, as it was needed in vmlinux.unstripped and
ELF_DETAILS was present in all architecture specific vmlinux linker
scripts. While this shuffle is fine for vmlinux, ELF_DETAILS and
COMMON_DISCARDS may be used by other linker scripts, such as the s390
and x86 compressed boot images, which may not expect to have a .modinfo
section. In certain circumstances, this could result in a bootloader
failing to load the compressed kernel [1].

Commit ddc6cbef3ef1 ("s390/boot/vmlinux.lds.S: Ensure bzImage ends with
SecureBoot trailer") recently addressed this for the s390 bzImage but
the same bug remains for arm, parisc, and x86. The presence of .modinfo
in the x86 bzImage was the root cause of the issue worked around with
commit d50f21091358 ("kbuild: align modinfo section for Secureboot
Authenticode EDK2 compat"). misc.c in arch/x86/boot/compressed includes
lib/decompress_unzstd.c, which in turn includes lib/xxhash.c and its
MODULE_LICENSE / MODULE_DESCRIPTION macros due to the STATIC definition.

Split .modinfo out from ELF_DETAILS into its own macro and handle it in
all vmlinux linker scripts. Discard .modinfo in the places where it was
previously being discarded from being in COMMON_DISCARDS, as it has
never been necessary in those uses.

Cc: stable@vger.kernel.org
Fixes: 3e86e4d74c04 ("kbuild: keep .modinfo section in vmlinux.unstripped")
Reported-by: Ed W 
Closes: https://lore.kernel.org/587f25e0-a80e-46a5-9f01-87cb40cfa377@wildgooses.com/ [1]
Tested-by: Ed W  # x86_64
Link: https://patch.msgid.link/20260225-separate-modinfo-from-elf-details-v1-1-387ced6baf4b@kernel.org
Signed-off-by: Nathan Chancellor

Convert 'alloc_obj' family to use the new default GFP_KERNEL argument

2026-02-22T01:09:51+00:00

This was done entirely with mindless brute force, using

    git grep -l '\