Pull clk fixes from Stephen Boyd:
 "A few Allwinner clk driver fixes:

   - Mark Allwinner A523 MBUS clock as critical to avoid
     system stalls

   - Fix names of CSI related clocks on Allwinner V3s. This
     includes changes to the driver, DT bindings and DT files.

   - Fix parents of TCON clock on Allwinner V3s"

* tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux:
  clk: sunxi-ng: v3s: Fix TCON clock parents
  clk: sunxi-ng: v3s: Fix CSI1 MCLK clock name
  clk: sunxi-ng: v3s: Fix CSI SCLK clock name
  clk: sunxi-ng: a523: Mark MBUS clock as critical

Pull ARM fixes from Russell King:

 - use an absolute path for asm/unified.h in KBUILD_AFLAGS to solve a
   regression caused by commit d5c8d6e0fa61 ("kbuild: Update assembler
   calls to use proper flags and language target")

 - fix dead code elimination binutils version check again

* tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rmk/linux:
  ARM: 9450/1: Fix allowing linker DCE with binutils < 2.36
  ARM: 9448/1: Use an absolute path to unified.h in KBUILD_AFLAGS

Pull SoC fixes from Arnd Bergmann:
 "These are two fixes that came in late, one addresses a regression on a
  rockchips based board, the other is for ensuring a consistent dt
  binding for a device added in 6.16 before the incorrect one makes it
  into a release"

* tag 'soc-fixes-6.16-3' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc:
  arm64: dts: rockchip: Drop netdev led-triggers on NanoPi R5S
  arm64: dts: allwinner: a523: Rename emac0 to gmac0

Commit e7607f7d6d81 ("ARM: 9443/1: Require linker to support KEEP within
OVERLAY for DCE") accidentally broke the binutils version restriction
that was added in commit 0d437918fb64 ("ARM: 9414/1: Fix build issue
with LD_DEAD_CODE_DATA_ELIMINATION"), reintroducing the segmentation
fault addressed by that workaround.

Restore the binutils version dependency by using
CONFIG_LD_CAN_USE_KEEP_IN_OVERLAY as an additional condition to ensure
that CONFIG_HAVE_LD_DEAD_CODE_DATA_ELIMINATION is only enabled with
binutils >= 2.36 and ld.lld >= 21.0.0.

Closes: https://lore.kernel.org/6739da7d-e555-407a-b5cb-e5681da71056@landley.net/
Closes: https://lore.kernel.org/CAFERDQ0zPoya5ZQfpbeuKVZEo_fKsonLf6tJbp32QnSGAtbi+Q@mail.gmail.com/

Cc: stable@vger.kernel.org
Fixes: e7607f7d6d81 ("ARM: 9443/1: Require linker to support KEEP within OVERLAY for DCE")
Reported-by: Rob Landley <rob@landley.net>
Tested-by: Rob Landley <rob@landley.net>
Reported-by: Martin Wetterwald <martin@wetterwald.eu>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>

After commit d5c8d6e0fa61 ("kbuild: Update assembler calls to use proper
flags and language target"), which updated as-instr to use the
'assembler-with-cpp' language option, the Kbuild version of as-instr
always fails internally for arch/arm with

  <command-line>: fatal error: asm/unified.h: No such file or directory
  compilation terminated.

because '-include' flags are now taken into account by the compiler
driver and as-instr does not have '$(LINUXINCLUDE)', so unified.h is not
found.

This went unnoticed at the time of the Kbuild change because the last
use of as-instr in Kbuild that arch/arm could reach was removed in 5.7
by commit 541ad0150ca4 ("arm: Remove 32bit KVM host support") but a
stable backport of the Kbuild change to before that point exposed this
potential issue if one were to be reintroduced.

Follow the general pattern of '-include' paths throughout the tree and
make unified.h absolute using '$(srctree)' to ensure KBUILD_AFLAGS can
be used independently.

Closes: https://lore.kernel.org/CACo-S-1qbCX4WAVFA63dWfHtrRHZBTyyr2js8Lx=Az03XHTTHg@mail.gmail.com/

Cc: stable@vger.kernel.org
Fixes: d5c8d6e0fa61 ("kbuild: Update assembler calls to use proper flags and language target")
Reported-by: KernelCI bot <bot@kernelci.org>
Reviewed-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>

Pull arm64 fixes from Will Deacon:
 "Two important arm64 fixes ahead of the 6.16 release.

  The first fixes a regression introduced during the merge window where
  the KVM UUID (which is used to advertise KVM-specific hypercalls for
  things like time synchronisation in the guest) was corrupted thanks to
  an endianness bug introduced when converting the code to use the
  UUID_INIT() helper.

  The second fixes a stack-pointer corruption issue during
  context-switch which has been observed in the wild when taking a
  pseudo-NMI with shadow call stack enabled.

  Summary:

   - Fix broken UUID value for the KVM/arm64 hypervisor SMCCC interface

   - Fix stack corruption on context-switch, primarily seen on (but not
     limited to) configurations with both pNMI and SCS enabled"

* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
  arm64/entry: Mask DAIF in cpu_switch_to(), call_on_irq_stack()
  arm64: kvm, smccc: Fix vendor uuid

Pull kvm fix from Paolo Bonzini:

 - Fix cleanup mistake (probably a cut-and-paste error) in a Xen
   hypercall

* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
  KVM: x86/xen: Fix cleanup logic in emulation of Xen schedop poll hypercalls

kvm_xen_schedop_poll does a kmalloc_array() when a VM polls the host
for more than one event channel potr (nr_ports > 1).

After the kmalloc_array(), the error paths need to go through the
"out" label, but the call to kvm_read_guest_virt() does not.

Fixes: 92c58965e965 ("KVM: x86/xen: Use kvm_read_guest_virt() instead of open-coding it badly")
Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Manuel Andreas <manuel.andreas@tum.de>
[Adjusted commit message. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

Sometimes the netdev triggers causes tasks to get blocked for more then
120 seconds, which in turn makes the (WAN) network port on the NanoPi
R5S fail to come up.
This results in the following (partial) trace:

  INFO: task kworker/0:1:11 blocked for more than 120 seconds.
        Not tainted 6.16-rc6+unreleased-arm64-cknow #1 Debian 6.16~rc6-1~exp1
  "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
  task:kworker/0:1     state:D stack:0     pid:11    tgid:11    ppid:2      task_flags:0x4208060 flags:0x00000010
  Workqueue: events_power_efficient reg_check_chans_work [cfg80211]
  Call trace:
   __switch_to+0xf8/0x168 (T)
   __schedule+0x3f8/0xda8
   schedule+0x3c/0x120
   schedule_preempt_disabled+0x2c/0x58
   __mutex_lock.constprop.0+0x4d0/0xab8
   __mutex_lock_slowpath+0x1c/0x30
   mutex_lock+0x50/0x68
   rtnl_lock+0x20/0x38
   reg_check_chans_work+0x40/0x478 [cfg80211]
   process_one_work+0x178/0x3e0
   worker_thread+0x260/0x390
   kthread+0x150/0x250
   ret_from_fork+0x10/0x20
  INFO: task kworker/0:1:11 is blocked on a mutex likely owned by task dhcpcd:615.
  task:dhcpcd          state:D stack:0     pid:615   tgid:615   ppid:614    task_flags:0x400140 flags:0x00000018
  Call trace:
   __switch_to+0xf8/0x168 (T)
   __schedule+0x3f8/0xda8
   schedule+0x3c/0x120
   schedule_preempt_disabled+0x2c/0x58
   rwsem_down_write_slowpath+0x1e4/0x750
   down_write+0x98/0xb0
   led_trigger_register+0x134/0x1c0
   phy_led_triggers_register+0xf4/0x258 [libphy]
   phy_attach_direct+0x30c/0x390 [libphy]
   phylink_fwnode_phy_connect+0xb0/0x138 [phylink]
   __stmmac_open+0xec/0x520 [stmmac]
   stmmac_open+0x4c/0xe8 [stmmac]
   __dev_open+0x130/0x2e0
   __dev_change_flags+0x1c4/0x248
   netif_change_flags+0x2c/0x80
   dev_change_flags+0x88/0xc8
   devinet_ioctl+0x35c/0x610
   inet_ioctl+0x204/0x260
   sock_do_ioctl+0x6c/0x140
   sock_ioctl+0x2e4/0x388
   __arm64_sys_ioctl+0xb4/0x120
   invoke_syscall+0x6c/0x100
   el0_svc_common.constprop.0+0x48/0xf0
   do_el0_svc+0x24/0x38
   el0_svc+0x3c/0x188
   el0t_64_sync_handler+0x10c/0x140
   el0t_64_sync+0x198/0x1a0

In order to not introduce a regression with kernel 6.16, drop the netdev
triggers for now while the problem is being investigated further.

Fixes: 1631cbdb8089 ("arm64: dts: rockchip: Improve LED config for NanoPi R5S")
Helped-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Diederik de Haas <didi.debian@cknow.org>
Link: https://lore.kernel.org/r/20250722123628.25660-1-didi.debian@cknow.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

`cpu_switch_to()` and `call_on_irq_stack()` manipulate SP to change
to different stacks along with the Shadow Call Stack if it is enabled.
Those two stack changes cannot be done atomically and both functions
can be interrupted by SErrors or Debug Exceptions which, though unlikely,
is very much broken : if interrupted, we can end up with mismatched stacks
and Shadow Call Stack leading to clobbered stacks.

In `cpu_switch_to()`, it can happen when SP_EL0 points to the new task,
but x18 stills points to the old task's SCS. When the interrupt handler
tries to save the task's SCS pointer, it will save the old task
SCS pointer (x18) into the new task struct (pointed to by SP_EL0),
clobbering it.

In `call_on_irq_stack()`, it can happen when switching from the task stack
to the IRQ stack and when switching back. In both cases, we can be
interrupted when the SCS pointer points to the IRQ SCS, but SP points to
the task stack. The nested interrupt handler pushes its return addresses
on the IRQ SCS. It then detects that SP points to the task stack,
calls `call_on_irq_stack()` and clobbers the task SCS pointer with
the IRQ SCS pointer, which it will also use !

This leads to tasks returning to addresses on the wrong SCS,
or even on the IRQ SCS, triggering kernel panics via CONFIG_VMAP_STACK
or FPAC if enabled.

This is possible on a default config, but unlikely.
However, when enabling CONFIG_ARM64_PSEUDO_NMI, DAIF is unmasked and
instead the GIC is responsible for filtering what interrupts the CPU
should receive based on priority.
Given the goal of emulating NMIs, pseudo-NMIs can be received by the CPU
even in `cpu_switch_to()` and `call_on_irq_stack()`, possibly *very*
frequently depending on the system configuration and workload, leading
to unpredictable kernel panics.

Completely mask DAIF in `cpu_switch_to()` and restore it when returning.
Do the same in `call_on_irq_stack()`, but restore and mask around
the branch.
Mask DAIF even if CONFIG_SHADOW_CALL_STACK is not enabled for consistency
of behaviour between all configurations.

Introduce and use an assembly macro for saving and masking DAIF,
as the existing one saves but only masks IF.

Cc: <stable@vger.kernel.org>
Signed-off-by: Ada Couprie Diaz <ada.coupriediaz@arm.com>
Reported-by: Cristian Prundeanu <cpru@amazon.com>
Fixes: 59b37fe52f49 ("arm64: Stash shadow stack pointer in the task struct on interrupt")
Tested-by: Cristian Prundeanu <cpru@amazon.com>
Acked-by: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20250718142814.133329-1-ada.coupriediaz@arm.com
Signed-off-by: Will Deacon <will@kernel.org>