linux-toradex.git/arch/arm64, branch v6.16 Linux kernel for Apalis and Colibri modules Merge tag 'soc-fixes-6.16-3' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc 2025-07-26T17:10:05+00:00 Linus Torvalds torvalds@linux-foundation.org 2025-07-26T17:10:05+00:00 6121f69c36337076fb0ffaa23acee3cf8cc5c931 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 
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
Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux 2025-07-24T15:50:55+00:00 Linus Torvalds torvalds@linux-foundation.org 2025-07-24T15:50:55+00:00 cef6c8c92fafa58fa04d8622e89ed4871d121fc3 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 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
arm64: dts: rockchip: Drop netdev led-triggers on NanoPi R5S 2025-07-22T20:33:36+00:00 Diederik de Haas didi.debian@cknow.org 2025-07-22T12:35:33+00:00 912b1f2a796ec73530a709b11821cb0c249fb23e 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> 
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>
arm64/entry: Mask DAIF in cpu_switch_to(), call_on_irq_stack() 2025-07-22T15:39:30+00:00 Ada Couprie Diaz ada.coupriediaz@arm.com 2025-07-18T14:28:14+00:00 d42e6c20de6192f8e4ab4cf10be8c694ef27e8cb `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> 
`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>
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm 2025-07-18T19:38:34+00:00 Linus Torvalds torvalds@linux-foundation.org 2025-07-18T19:38:34+00:00 c7de79e662b8681f54196c107281f1e63c26a3db Pull kvm fixes from Paolo Bonzini: "ARM: - Fix use of u64_replace_bits() in adjusting the guest's view of MDCR_EL2.HPMN RISC-V: - Fix an issue related to timer cleanup when exiting to user-space - Fix a race-condition in updating interrupts enabled for the guest when IMSIC is hardware-virtualized x86: - Reject KVM_SET_TSC_KHZ for guests with a protected TSC (currently only TDX) - Ensure struct kvm_tdx_capabilities fields that are not explicitly set by KVM are zeroed Documentation: - Explain how KVM contributions should be made testable - Fix a formatting goof in the TDX documentation" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: KVM: TDX: Don't report base TDVMCALLs KVM: VMX: Ensure unused kvm_tdx_capabilities fields are zeroed out KVM: Documentation: document how KVM is tested KVM: Documentation: minimal updates to review-checklist.rst KVM: x86: Reject KVM_SET_TSC_KHZ vCPU ioctl for TSC protected guest RISC-V: KVM: Move HGEI[E|P] CSR access to IMSIC virtualization RISC-V: KVM: Disable vstimecmp before exiting to user-space Documentation: KVM: Fix unexpected unindent warning KVM: arm64: Fix enforcement of upper bound on MDCR_EL2.HPMN 
Pull kvm fixes from Paolo Bonzini:
 "ARM:

   - Fix use of u64_replace_bits() in adjusting the guest's view of
     MDCR_EL2.HPMN

  RISC-V:

   - Fix an issue related to timer cleanup when exiting to user-space

   - Fix a race-condition in updating interrupts enabled for the guest
     when IMSIC is hardware-virtualized

  x86:

   - Reject KVM_SET_TSC_KHZ for guests with a protected TSC (currently
     only TDX)

   - Ensure struct kvm_tdx_capabilities fields that are not explicitly
     set by KVM are zeroed

  Documentation:

   - Explain how KVM contributions should be made testable

   - Fix a formatting goof in the TDX documentation"

* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
  KVM: TDX: Don't report base TDVMCALLs
  KVM: VMX: Ensure unused kvm_tdx_capabilities fields are zeroed out
  KVM: Documentation: document how KVM is tested
  KVM: Documentation: minimal updates to review-checklist.rst
  KVM: x86: Reject KVM_SET_TSC_KHZ vCPU ioctl for TSC protected guest
  RISC-V: KVM: Move HGEI[E|P] CSR access to IMSIC virtualization
  RISC-V: KVM: Disable vstimecmp before exiting to user-space
  Documentation: KVM: Fix unexpected unindent warning
  KVM: arm64: Fix enforcement of upper bound on MDCR_EL2.HPMN
Merge tag 'sunxi-fixes-for-6.16' of https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux into arm/fixes 2025-07-18T06:24:07+00:00 Arnd Bergmann arnd@arndb.de 2025-07-18T06:23:59+00:00 816309d500ac34b9ae3ff88f130ca7dbbe467bfb Allwinner fixes for 6.16 Only one fix: Correct the name of the A523's EMAC0 to GMAC0, as seen in the SoC's datasheets. The matching DT binding change is in the net tree. * tag 'sunxi-fixes-for-6.16' of https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux: arm64: dts: allwinner: a523: Rename emac0 to gmac0 Signed-off-by: Arnd Bergmann <arnd@arndb.de> 
Allwinner fixes for 6.16

Only one fix:

Correct the name of the A523's EMAC0 to GMAC0, as seen in the SoC's
datasheets. The matching DT binding change is in the net tree.

* tag 'sunxi-fixes-for-6.16' of https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux:
  arm64: dts: allwinner: a523: Rename emac0 to gmac0

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Merge tag 'kvmarm-fixes-6.16-6' of git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD 2025-07-15T17:32:23+00:00 Paolo Bonzini pbonzini@redhat.com 2025-07-15T17:32:23+00:00 be8543845da59901a8326a0df5e3630684ac028b KVM/arm64 fixes for 6.16, take #6 - Fix use of u64_replace_bits() in adjusting the guest's view of MDCR_EL2.HPMN. 
KVM/arm64 fixes for 6.16, take #6

- Fix use of u64_replace_bits() in adjusting the guest's view of
  MDCR_EL2.HPMN.
Merge tag 'soc-fixes-6.16-2' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc 2025-07-15T16:26:33+00:00 Linus Torvalds torvalds@linux-foundation.org 2025-07-15T16:26:33+00:00 4664a4ddb9211a3513aa769453e3a1095fc806d0 Pull SoC fixes from Arnd Bergmann: "There are 18 devicetree fixes for three arm64 plaforms: Qualcomm Snapdragon, Rockchips and NXP i.MX. These get updated to more correctly describe the hardware, fixing issues with: - real-time clock on Snapdragon based laptops - SD card detection, PCI probing and HDMI/DDC communication on Rockchips - ethernet and SPI probing on certain i.MX based boards - a regression with the i.MX watchdog Aside from the devicetree fixes, there are two additional fixes for the merged ASPEED LPC snoop driver that saw some changes in 6.16, and one additional driver enabled in arm64 defconfig to fix CPU frequency scaling" * tag 'soc-fixes-6.16-2' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (21 commits) arm64: dts: freescale: imx8mm-verdin: Keep LDO5 always on soc: aspeed: lpc-snoop: Don't disable channels that aren't enabled soc: aspeed: lpc-snoop: Cleanup resources in stack-order arm64: dts: imx95: Correct the DMA interrupter number of pcie0_ep arm64: dts: rockchip: Add missing fan-supply to rk3566-quartz64-a arm64: dts: rockchip: use cs-gpios for spi1 on ringneck arm64: dts: add big-endian property back into watchdog node arm64: dts: imx95-15x15-evk: fix the overshoot issue of NETC arm64: dts: imx95-19x19-evk: fix the overshoot issue of NETC arm64: dts: rockchip: list all CPU supplies on ArmSoM Sige5 arm64: dts: imx8mp-venice-gw74xx: fix TPM SPI frequency arm64: dts: imx8mp-venice-gw73xx: fix TPM SPI frequency arm64: dts: imx8mp-venice-gw72xx: fix TPM SPI frequency arm64: dts: imx8mp-venice-gw71xx: fix TPM SPI frequency arm64: dts: qcom: x1e80100: describe uefi rtc offset arm64: dts: qcom: sc8280xp-x13s: describe uefi rtc offset arm64: defconfig: Enable Qualcomm CPUCP mailbox driver arm64: dts: rockchip: Add cd-gpios for sdcard detect on Cool Pi 4B arm64: dts: rockchip: Add cd-gpios for sdcard detect on Cool Pi CM5 arm64: dts: rockchip: Adjust the HDMI DDC IO driver strength for rk3588 ... 
Pull SoC fixes from Arnd Bergmann:
 "There are 18 devicetree fixes for three arm64 plaforms: Qualcomm
  Snapdragon, Rockchips and NXP i.MX. These get updated to more
  correctly describe the hardware, fixing issues with:

   - real-time clock on Snapdragon based laptops

   - SD card detection, PCI probing and HDMI/DDC communication on
     Rockchips

   - ethernet and SPI probing on certain i.MX based boards

   - a regression with the i.MX watchdog

  Aside from the devicetree fixes, there are two additional fixes for
  the merged ASPEED LPC snoop driver that saw some changes in 6.16, and
  one additional driver enabled in arm64 defconfig to fix CPU frequency
  scaling"

* tag 'soc-fixes-6.16-2' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (21 commits)
  arm64: dts: freescale: imx8mm-verdin: Keep LDO5 always on
  soc: aspeed: lpc-snoop: Don't disable channels that aren't enabled
  soc: aspeed: lpc-snoop: Cleanup resources in stack-order
  arm64: dts: imx95: Correct the DMA interrupter number of pcie0_ep
  arm64: dts: rockchip: Add missing fan-supply to rk3566-quartz64-a
  arm64: dts: rockchip: use cs-gpios for spi1 on ringneck
  arm64: dts: add big-endian property back into watchdog node
  arm64: dts: imx95-15x15-evk: fix the overshoot issue of NETC
  arm64: dts: imx95-19x19-evk: fix the overshoot issue of NETC
  arm64: dts: rockchip: list all CPU supplies on ArmSoM Sige5
  arm64: dts: imx8mp-venice-gw74xx: fix TPM SPI frequency
  arm64: dts: imx8mp-venice-gw73xx: fix TPM SPI frequency
  arm64: dts: imx8mp-venice-gw72xx: fix TPM SPI frequency
  arm64: dts: imx8mp-venice-gw71xx: fix TPM SPI frequency
  arm64: dts: qcom: x1e80100: describe uefi rtc offset
  arm64: dts: qcom: sc8280xp-x13s: describe uefi rtc offset
  arm64: defconfig: Enable Qualcomm CPUCP mailbox driver
  arm64: dts: rockchip: Add cd-gpios for sdcard detect on Cool Pi 4B
  arm64: dts: rockchip: Add cd-gpios for sdcard detect on Cool Pi CM5
  arm64: dts: rockchip: Adjust the HDMI DDC IO driver strength for rk3588
  ...
Merge tag 'qcom-arm64-defconfig-fixes-for-6.16' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/fixes 2025-07-11T11:41:10+00:00 Arnd Bergmann arnd@arndb.de 2025-07-11T11:41:08+00:00 8f0837fdc5d832f0cd953f66db0cbfb2fa8909d2 Qualcomm Arm64 defconfig fixes for v6.16 The v6.16 driver and DeviceTree updates described and implemented CPU frequency scaling for the Qualcomm X Elite platform. But the necessary CPUCP mailbox driver was not enabled, resulting in a series of error messages being logged during boot (and no CPU frequency scaling). Enable the missing drivers to silence the errors, and enable CPU frequency scaling on this platform. * tag 'qcom-arm64-defconfig-fixes-for-6.16' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux: arm64: defconfig: Enable Qualcomm CPUCP mailbox driver Signed-off-by: Arnd Bergmann <arnd@arndb.de> 
Qualcomm Arm64 defconfig fixes for v6.16

The v6.16 driver and DeviceTree updates described and implemented CPU
frequency scaling for the Qualcomm X Elite platform. But the necessary
CPUCP mailbox driver was not enabled, resulting in a series of error
messages being logged during boot (and no CPU frequency scaling).

Enable the missing drivers to silence the errors, and enable CPU
frequency scaling on this platform.

* tag 'qcom-arm64-defconfig-fixes-for-6.16' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux:
  arm64: defconfig: Enable Qualcomm CPUCP mailbox driver

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Merge tag 'qcom-arm64-fixes-for-6.16' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/fixes 2025-07-11T11:40:59+00:00 Arnd Bergmann arnd@arndb.de 2025-07-11T11:39:12+00:00 f2ebacd34eeb73081eadfba5e6e99ea967365911 Qualcomm DeviceTree fixes for v6.16 The RTC DeviceTree binding was changed in v6.16, to require an explicit flag indicating that we store RTC offset in in an UEFI variable. The result sent X Elite and Lenovo Thinkpad X13s users back to 1970, add the flag to explicitly select the correct configuration for these devices. * tag 'qcom-arm64-fixes-for-6.16' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux: arm64: dts: qcom: x1e80100: describe uefi rtc offset arm64: dts: qcom: sc8280xp-x13s: describe uefi rtc offset Signed-off-by: Arnd Bergmann <arnd@arndb.de> 
Qualcomm DeviceTree fixes for v6.16

The RTC DeviceTree binding was changed in v6.16, to require an explicit
flag indicating that we store RTC offset in in an UEFI variable.

The result sent X Elite and Lenovo Thinkpad X13s users back to 1970, add
the flag to explicitly select the correct configuration for these
devices.

* tag 'qcom-arm64-fixes-for-6.16' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux:
  arm64: dts: qcom: x1e80100: describe uefi rtc offset
  arm64: dts: qcom: sc8280xp-x13s: describe uefi rtc offset

Signed-off-by: Arnd Bergmann <arnd@arndb.de>