aboutsummaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2026-01-29spi: dw: Remove not-going-to-be-supported code for Baikal SoCAndy Shevchenko3-359/+0
As noticed in the discussion [1] the Baikal SoC and platforms are not going to be finalized, hence remove stale code. Link: https://lore.kernel.org/lkml/22b92ddf-6321-41b5-8073-f9c7064d3432@infradead.org/ [1] Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20260127210541.4068379-1-andriy.shevchenko@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-29Merge tag 'v6.20-rockchip-drivers1' of ↵Arnd Bergmann1-29/+28
https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into soc/drivers Two fixes for the default-settings code for the General-Register-Files, which sets system defaults for some settings like disabling the automatic jtag/sdmmc switching. One is a corrected register-offset and the other makes the code actually look for all matched GRF instances, which it didn't do before. * tag 'v6.20-rockchip-drivers1' of https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip: soc: rockchip: grf: Support multiple grf to be handled soc: rockchip: grf: Fix wrong RK3576_IOCGRF_MISC_CON definition Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2026-01-29Merge tag 'mvebu-arm-6.20-1' of ↵Arnd Bergmann1-6/+3
git://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu into soc/drivers mvebu arm for 6.20 (part 1) Simplify Dove PMU OF child node iteration with scoped loops * tag 'mvebu-arm-6.20-1' of git://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu: soc: dove: pmu: Simplify with scoped for each OF child loop Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2026-01-29Merge tag 'reset-for-v6.20' of https://git.pengutronix.de/git/pza/linux into ↵Arnd Bergmann12-183/+630
soc/drivers Reset controller updates for v6.20 * Add a compatible to the reset-gpio driver, suppress the sysfs bind attributes, and propagate GPIO API errors. * Add support for the i.MX8ULP SIM LPAV reset controller. * Add RZ/G3S USBPHY suspend/resume support. * Enable reset-k230 by default on ARCH_CANAAN * Add support for the SpacemiT K3 SoC reset controller. * Merge the 'spacemit-clkrst-v6.20-3' tag, shared with the clk tree, as a dependency for the SpacemiT changes. * tag 'reset-for-v6.20' of https://git.pengutronix.de/git/pza/linux: reset: spacemit: Add SpacemiT K3 reset driver reset: spacemit: Extract common K1 reset code reset: Create subdirectory for SpacemiT drivers dt-bindings: soc: spacemit: Add K3 reset support and IDs reset: canaan: k230: drop OF dependency and enable by default reset: rzg2l-usbphy-ctrl: Add suspend/resume support reset: rzg2l-usbphy-ctrl: Propagate the return value of regmap_field_update_bits() reset: gpio: check the return value of gpiod_set_value_cansleep() reset: imx8mp-audiomix: Support i.MX8ULP SIM LPAV reset: imx8mp-audiomix: Extend the driver usage reset: imx8mp-audiomix: Switch to using regmap API reset: imx8mp-audiomix: Drop unneeded macros reset: gpio: suppress bind attributes in sysfs clk: spacemit: k3: extract common header reset: spacemit: fix auxiliary device id clk: spacemit: prepare common ccu header reset: gpio: add the "compatible" property Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2026-01-29Merge tag 'memory-controller-drv-6.20' of ↵Arnd Bergmann1-16/+22
https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl into soc/drivers Memory controller drivers for v6.20 1. Mediatek SMI: Fix old struct device reference leaks during error paths and device unbinding. 2. Memory Devicetree bindings: refactor existing LPDDR bindings and add bindings for DDR4 SDRAM. These will be used for example in stm32mp257f-ev1 DTS. * tag 'memory-controller-drv-6.20' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl: dt-bindings: memory: SDRAM channel: standardise node name dt-bindings: memory: add DDR4 channel compatible dt-bindings: memory: factorise LPDDR channel binding into SDRAM channel dt-bindings: memory: introduce DDR4 dt-bindings: memory: factorise LPDDR props into SDRAM props memory: mtk-smi: clean up device link creation memory: mtk-smi: fix device leak on larb probe memory: mtk-smi: fix device leaks on common probe Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2026-01-29Merge tag 'amlogic-drivers-for-v6.20' of ↵Arnd Bergmann1-0/+1
https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux into soc/drivers Amlogic Drivers for v6.20: - add new SoC id for S905Y4 * tag 'amlogic-drivers-for-v6.20' of https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux: soc: amlogic: meson-gx-socinfo: add new SoC id for S905Y4 Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2026-01-29Merge tag 'omap-for-v6.20/drivers-signed' of ↵Arnd Bergmann3-13/+6
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap into soc/drivers drivers: bus & hwsplinlock updates for OMAP * tag 'omap-for-v6.20/drivers-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap: hwspinlock: omap: Handle devm_pm_runtime_enable() errors bus: omap-ocp2scp: enable compile testing bus: omap-ocp2scp: fix OF populate on driver rebind Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2026-01-29Merge tag 'mtk-soc-for-v6.20' of ↵Arnd Bergmann5-41/+480
https://git.kernel.org/pub/scm/linux/kernel/git/mediatek/linux into soc/drivers MediaTek soc driver updates This adds: - A socinfo entry for the MT8371 Genio 520 SoC - Support for the Dynamic Voltage and Frequency Scaling Resource Controller (DVFSRC) version 4, found in the new MediaTek Kompanio Ultra (MT8196) SoC - Initial support for the CMDQ mailbox found in the MT8196. - A memory leak fix in the MediaTek SVS driver's debug ops. * tag 'mtk-soc-for-v6.20' of https://git.kernel.org/pub/scm/linux/kernel/git/mediatek/linux: soc: mediatek: mtk-cmdq: Add mminfra_offset adjustment for DRAM addresses soc: mediatek: mtk-cmdq: Extend cmdq_pkt_write API for SoCs without subsys ID soc: mediatek: mtk-cmdq: Add pa_base parsing for hardware without subsys ID support soc: mediatek: mtk-cmdq: Add cmdq_get_mbox_priv() in cmdq_pkt_create() mailbox: mtk-cmdq: Add driver data to support for MT8196 mailbox: mtk-cmdq: Add mminfra_offset configuration for DRAM transaction mailbox: mtk-cmdq: Add GCE hardware virtualization configuration mailbox: mtk-cmdq: Add cmdq private data to cmdq_pkt for generating instruction soc: mediatek: mtk-dvfsrc: Rework bandwidth calculations soc: mediatek: mtk-dvfsrc: Get and Enable DVFSRC clock soc: mediatek: mtk-dvfsrc: Add support for DVFSRCv4 and MT8196 soc: mediatek: mtk-dvfsrc: Write bandwidth to EMI DDR if present soc: mediatek: mtk-dvfsrc: Add a new callback for calc_dram_bw soc: mediatek: mtk-dvfsrc: Add and propagate DVFSRC bandwidth type soc: mediatek: mtk-dvfsrc: Change error check for DVFSRCv4 START cmd dt-bindings: soc: mediatek: dvfsrc: Document clock soc: mediatek: mtk-socinfo: Add entry for MT8371AV/AZA Genio 520 soc: mediatek: svs: Fix memory leak in svs_enable_debug_write() Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2026-01-29Merge tag 'apple-soc-drivers-6.20' of ↵Arnd Bergmann1-0/+16
https://git.kernel.org/pub/scm/linux/kernel/git/sven/linux into soc/drivers Apple SoC driver updates for 6.20 - Add a poweroff function to the RTKit library which will be required for the first USB4/Thunderbolt series I hope to submit next cycle. * tag 'apple-soc-drivers-6.20' of https://git.kernel.org/pub/scm/linux/kernel/git/sven/linux: soc: apple: rtkit: Add function to poweroff Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2026-01-29Merge tag 'qcom-drivers-fixes-for-6.19' of ↵Arnd Bergmann1-2/+3
https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/fixes Qualcomm driver fix for v6.19 The changes to the logic in the Qualcomm SMEM driver for separating "failed to probe" from "not yet probed", did not change the qcom_smem_is_available() function, with the result that clients sees SMEM as always available. Clients might then proceed to interact with SMEM in codepaths that aren't suited to cope with -EPROBE_DEFER. * tag 'qcom-drivers-fixes-for-6.19' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux: soc: qcom: smem: fix qcom_smem_is_available and check if __smem is valid Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2026-01-29gpio: tegra186: Add support for Tegra264Prathamesh Shete1-2/+88
Extend the existing Tegra186 GPIO controller driver with support for the GPIO controller found on Tegra264. Use the "wakeup-parent" phandle from the GPIO device tree node to ensure the GPIO driver associates with the intended PMC device. Relying only on compatible-based lookup can select an unexpected PMC node, so fall back to compatible-based lookup when the phandle is not present. Signed-off-by: Prathamesh Shete <pshete@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Acked-by: Thierry Reding <treding@nvidia.com> Link: https://patch.msgid.link/20260128085114.1137725-2-pshete@nvidia.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-01-28net/mlx5e: Skip ESN replay window setup for IPsec crypto offloadJianbo Liu1-1/+2
Commit a5e400a985df ("net/mlx5e: Honor user choice of IPsec replay window size") introduced logic to setup the ESN replay window size. This logic is only valid for packet offload. However, the check to skip this block only covered outbound offloads. It was not skipped for crypto offload, causing it to fall through to the new switch statement and trigger its WARN_ON default case (for instance, if a window larger than 256 bits was configured). Fix this by amending the condition to also skip the replay window setup if the offload type is not XFRM_DEV_OFFLOAD_PACKET. Fixes: a5e400a985df ("net/mlx5e: Honor user choice of IPsec replay window size") Signed-off-by: Jianbo Liu <jianbol@nvidia.com> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1769503961-124173-5-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-28net/mlx5: Fix vhca_id access call trace use before allocParav Pandit4-11/+21
HCA CAP structure is allocated in mlx5_hca_caps_alloc(). mlx5_mdev_init() mlx5_hca_caps_alloc() And HCA CAP is read from the device in mlx5_init_one(). The vhca_id's debugfs file is published even before above two operations are done. Due to this when user reads the vhca id before the initialization, following call trace is observed. Fix this by deferring debugfs publication until the HCA CAP is allocated and read from the device. BUG: kernel NULL pointer dereference, address: 0000000000000004 PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP PTI CPU: 23 UID: 0 PID: 6605 Comm: cat Kdump: loaded Not tainted 6.18.0-rc7-sf+ #110 PREEMPT(full) Hardware name: Supermicro SYS-6028U-TR4+/X10DRU-i+, BIOS 2.0b 08/09/2016 RIP: 0010:vhca_id_show+0x17/0x30 [mlx5_core] Code: cb 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 48 8b 47 70 48 c7 c6 45 f0 12 c1 48 8b 80 70 03 00 00 <8b> 50 04 0f ca 0f b7 d2 e8 8c 82 47 cb 31 c0 c3 cc cc cc cc 0f 1f RSP: 0018:ffffd37f4f337d40 EFLAGS: 00010203 RAX: 0000000000000000 RBX: ffff8f18445c9b40 RCX: 0000000000000001 RDX: ffff8f1109825180 RSI: ffffffffc112f045 RDI: ffff8f18445c9b40 RBP: 0000000000000000 R08: 0000645eac0d2928 R09: 0000000000000006 R10: ffffd37f4f337d48 R11: 0000000000000000 R12: ffffd37f4f337dd8 R13: ffffd37f4f337db0 R14: ffff8f18445c9b68 R15: 0000000000000001 FS: 00007f3eea099580(0000) GS:ffff8f2090f1f000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000004 CR3: 00000008b64e4006 CR4: 00000000003726f0 Call Trace: <TASK> seq_read_iter+0x11f/0x4f0 ? _raw_spin_unlock+0x15/0x30 ? do_anonymous_page+0x104/0x810 seq_read+0xf6/0x120 ? srso_alias_untrain_ret+0x1/0x10 full_proxy_read+0x5c/0x90 vfs_read+0xad/0x320 ? handle_mm_fault+0x1ab/0x290 ksys_read+0x52/0xd0 do_syscall_64+0x61/0x11e0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Fixes: dd3dd7263cde ("net/mlx5: Expose vhca_id to debugfs") Signed-off-by: Parav Pandit <parav@nvidia.com> Reviewed-by: Shay Drori <shayd@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1769503961-124173-4-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-28net/mlx5: fs, Fix inverted cap check in tx flow table root disconnectShay Drory1-1/+2
The capability check for reset_root_to_default was inverted, causing the function to return -EOPNOTSUPP when the capability IS supported, rather than when it is NOT supported. Fix the capability check condition. Fixes: 3c9c34c32bc6 ("net/mlx5: fs, Command to control TX flow table root") Signed-off-by: Shay Drory <shayd@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1769503961-124173-2-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-28net: phy: micrel: fix clk warning when removing the driverWei Fang1-4/+13
Since the commit 25c6a5ab151f ("net: phy: micrel: Dynamically control external clock of KSZ PHY"), the clock of Micrel PHY has been enabled by phy_driver::resume() and disabled by phy_driver::suspend(). However, devm_clk_get_optional_enabled() is used in kszphy_probe(), so the clock will automatically be disabled when the device is unbound from the bus. Therefore, this could cause the clock to be disabled twice, resulting in clk driver warnings. For example, this issue can be reproduced on i.MX6ULL platform, and we can see the following logs when removing the FEC MAC drivers. $ echo 2188000.ethernet > /sys/bus/platform/drivers/fec/unbind $ echo 20b4000.ethernet > /sys/bus/platform/drivers/fec/unbind [ 109.758207] ------------[ cut here ]------------ [ 109.758240] WARNING: drivers/clk/clk.c:1188 at clk_core_disable+0xb4/0xd0, CPU#0: sh/639 [ 109.771011] enet2_ref already disabled [ 109.793359] Call trace: [ 109.822006] clk_core_disable from clk_disable+0x28/0x34 [ 109.827340] clk_disable from clk_disable_unprepare+0xc/0x18 [ 109.833029] clk_disable_unprepare from devm_clk_release+0x1c/0x28 [ 109.839241] devm_clk_release from devres_release_all+0x98/0x100 [ 109.845278] devres_release_all from device_unbind_cleanup+0xc/0x70 [ 109.851571] device_unbind_cleanup from device_release_driver_internal+0x1a4/0x1f4 [ 109.859170] device_release_driver_internal from bus_remove_device+0xbc/0xe4 [ 109.866243] bus_remove_device from device_del+0x140/0x458 [ 109.871757] device_del from phy_mdio_device_remove+0xc/0x24 [ 109.877452] phy_mdio_device_remove from mdiobus_unregister+0x40/0xac [ 109.883918] mdiobus_unregister from fec_enet_mii_remove+0x40/0x78 [ 109.890125] fec_enet_mii_remove from fec_drv_remove+0x4c/0x158 [ 109.896076] fec_drv_remove from device_release_driver_internal+0x17c/0x1f4 [ 109.962748] WARNING: drivers/clk/clk.c:1047 at clk_core_unprepare+0xfc/0x13c, CPU#0: sh/639 [ 109.975805] enet2_ref already unprepared [ 110.002866] Call trace: [ 110.031758] clk_core_unprepare from clk_unprepare+0x24/0x2c [ 110.037440] clk_unprepare from devm_clk_release+0x1c/0x28 [ 110.042957] devm_clk_release from devres_release_all+0x98/0x100 [ 110.048989] devres_release_all from device_unbind_cleanup+0xc/0x70 [ 110.055280] device_unbind_cleanup from device_release_driver_internal+0x1a4/0x1f4 [ 110.062877] device_release_driver_internal from bus_remove_device+0xbc/0xe4 [ 110.069950] bus_remove_device from device_del+0x140/0x458 [ 110.075469] device_del from phy_mdio_device_remove+0xc/0x24 [ 110.081165] phy_mdio_device_remove from mdiobus_unregister+0x40/0xac [ 110.087632] mdiobus_unregister from fec_enet_mii_remove+0x40/0x78 [ 110.093836] fec_enet_mii_remove from fec_drv_remove+0x4c/0x158 [ 110.099782] fec_drv_remove from device_release_driver_internal+0x17c/0x1f4 After analyzing the process of removing the FEC driver, as shown below, it can be seen that the clock was disabled twice by the PHY driver. fec_drv_remove() --> fec_enet_close() --> phy_stop() --> phy_suspend() --> kszphy_suspend() #1 The clock is disabled --> fec_enet_mii_remove() --> mdiobus_unregister() --> phy_mdio_device_remove() --> device_del() --> devm_clk_release() #2 The clock is disabled again Therefore, devm_clk_get_optional() is used to fix the above issue. And to avoid the issue mentioned by the commit 985329462723 ("net: phy: micrel: use devm_clk_get_optional_enabled for the rmii-ref clock"), the clock is enabled by clk_prepare_enable() to get the correct clock rate. Fixes: 25c6a5ab151f ("net: phy: micrel: Dynamically control external clock of KSZ PHY") Signed-off-by: Wei Fang <wei.fang@nxp.com> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Link: https://patch.msgid.link/20260126081544.983517-1-wei.fang@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-28net: ethernet: neterion: s2io: remove unused driverEthan Nelson-Moore7-10697/+0
The s2io driver supports Exar (formerly Neterion and S2io) PCI-X 10 Gigabit Ethernet cards. Hardware supporting PCI-X has not been manufactured in years. On x86, it was quickly replaced by PCIe. While it stuck around longer on POWER hardware, the last POWER hardware to support it was POWER7, which is not supported by ppc64le Linux distributions. The last supported mainstream ppc64 Linux distribution was RHEL 7; while it is still supported under ELS, ELS is only available for x86 and IBM Z. It is possible to use many PCI-X cards in standard PCI slots (which are still available on new motherboards), but it does not make sense to do so for 10 Gigabit Ethernet because the maximum bandwidth of standard PCI is only 1067 Mbps. It is therefore highly unlikely that this driver is still being used. Remove the driver, and move the former maintainer to the CREDITS file (restoring credit for the vxge driver, which was removed in commit f05643a0f60b ("eth: remove neterion/vxge"). Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com> Link: https://patch.msgid.link/20260126031352.22997-1-enelsonmoore@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-28net/mlx5e: don't assume psp tx skbs are ipv6 csum handlingDaniel Zahka1-6/+11
mlx5e_psp_handle_tx_skb() assumes skbs are ipv6 when doing a partial TCP checksum with tso. Make correctly mlx5e_psp_handle_tx_skb() handle ipv4 packets. Fixes: e5a1861a298e ("net/mlx5e: Implement PSP Tx data path") Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com> Link: https://patch.msgid.link/20260126-dzahka-fix-tx-csum-partial-v2-1-0a905590ea5f@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-28Merge branch '10GbE' of ↵Jakub Kicinski3-21/+16
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue Tony Nguyen says: ==================== Intel Wired LAN Driver Updates 2026-01-27 (ixgbe, ice) For ixgbe: Kohei Enju adjusts the cleanup path on firmware error to resolve some memory leaks and removes an instance of double init, free on ACI mutex. For ice: Aaron Ma adds NULL checks for q_vectors to avoid NULL pointer dereference. Jesse Brandeburg removes UDP checksum mismatch from being counted in Rx errors. * '10GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue: ice: stop counting UDP csum mismatch as rx_errors ice: Fix NULL pointer dereference in ice_vsi_set_napi_queues ixgbe: don't initialize aci lock in ixgbe_recovery_probe() ixgbe: fix memory leaks in the ixgbe_recovery_probe() path ==================== Link: https://patch.msgid.link/20260127223047.3979404-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-28declance: Remove IRQF_ONESHOTSebastian Andrzej Siewior1-1/+1
Passing IRQF_ONESHOT ensures that the interrupt source is masked until the secondary (threaded) handler is done. If only a primary handler is used then the flag makes no sense because the interrupt can not fire (again) while its handler is running. The flag also disallows force-threading of the primary handler and the irq-core will warn about this as of commit aef30c8d569c0 ("genirq: Warn about using IRQF_ONESHOT without a threaded handler"). The IRQF_ONESHOT flag was added in commit 0fabe1021f8bc ("MIPS: DECstation I/O ASIC DMA interrupt classes"). It moved clear_ioasic_dma_irq() from the driver into the irq-chip. For EOI interrupts the clear_ioasic_dma_irq() callback is now invoked as ->irq_eoi() which is invoked after the IRQ was handled while the interrupt is masked due to IRQF_ONESHOT. Without IRQF_ONESHOT it would be invoked while interrupt is unmasked (but interrupts are disabled). If it is *required* to invoke EOI-ack while the interrupt is masked (and not a misunderstanding) due to irq-chip cascading/ hierarchical reasons then using handle_fasteoi_mask_irq() as flow-handler would be the right way to do so. Remove IRQF_ONESHOT to irqflags. Cc: Andrew Lunn <andrew+netdev@lunn.ch> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Acked-by: Maciej W. Rozycki <macro@orcam.me.uk> Link: https://patch.msgid.link/20260127135334.qUEaYP9G@linutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-28bcache: fix I/O accounting leak in detached_dev_do_requestShida Zhang1-0/+1
When a bcache device is detached, discard requests are completed immediately. However, the I/O accounting started in cached_dev_make_request() is not ended, leading to 100% disk utilization reports in iostat. Add the missing bio_end_io_acct() call. Fixes: cafe56359144 ("bcache: A block layer cache") Signed-off-by: Shida Zhang <zhangshida@kylinos.cn> Acked-by: Coly Li <colyli@fnnas.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-01-28bcache: remove dead code in detached_dev_do_requestShida Zhang1-5/+0
bio_alloc_clone() with GFP_NOIO and a mempool will not return NULL. Remove the unnecessary NULL check. Suggested-by: Christoph Hellwig <hch@infradead.org> Signed-off-by: Shida Zhang <zhangshida@kylinos.cn> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-01-29spi: cadence-qspi: Add Renesas RZ/N1 supportMark Brown1-58/+71
Merge series from "Miquel Raynal (Schneider Electric)" <miquel.raynal@bootlin.com>: This series adds support for the QSPI controller available on Renesas RZ/N1S and RZ/N1D SoC. It has been tested with a custom board (see last SPI patch for details), but has been tested by Wolfram (thank you!) on the DB board. Link: https://lore.kernel.org/linux-devicetree/20260116114852.52948-2-wsa+renesas@sang-engineering.com/ Adding support for this SoC required a few adaptations in the Cadence QSPI driver. The bulk of the work is in the few last patches. Everything else is just misc style fixes and improvements which bothered me while I was wandering. In order to support all constraints, I sometimes used a new quirk (for the write protection feature and the "no indirect mode"), and sometimes used the compatible directly. The ones I thought might not be RZ/N1 specific have been implemented under the form of a quirk, in order to ease their reuse. The other adaptations, which I believe are more Renesas specific, have been handled using the compatible. This is all very arbitrary, and can be discussed.
2026-01-29regmap: reg_default_cb for flat cache defaultsMark Brown5-1/+117
Merge series from "Sheetal ." <sheetal@nvidia.com>: This series adds a reg_default_cb callback for REGCACHE_FLAT to provide defaults for registers not listed in reg_defaults. Defaults are loaded eagerly during regcache init and the callback can use writeable_reg to filter valid addresses and avoid holes. Tegra ASoC drivers set reg_default_cb and add writeable_reg filtering for AHUB RX holes to prevent invalid addresses from being marked valid.
2026-01-29of: reserved_mem: Allow reserved_mem framework detect "cma=" kernel paramOreoluwa Babatunde1-2/+17
When initializing the default cma region, the "cma=" kernel parameter takes priority over a DT defined linux,cma-default region. Hence, give the reserved_mem framework the ability to detect this so that the DT defined cma region can skip initialization accordingly. Signed-off-by: Oreoluwa Babatunde <oreoluwa.babatunde@oss.qualcomm.com> Tested-by: Joy Zou <joy.zou@nxp.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Fixes: 8a6e02d0c00e ("of: reserved_mem: Restructure how the reserved memory regions are processed") Fixes: 2c223f7239f3 ("of: reserved_mem: Restructure call site for dma_contiguous_early_fixup()") Link: https://lore.kernel.org/r/20251210002027.1171519-1-oreoluwa.babatunde@oss.qualcomm.com [mszyprow: rebased onto v6.19-rc1, added fixes tags, added a stub for cma_skip_dt_default_reserved_mem() if no CONFIG_DMA_CMA is set] Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
2026-01-29firewire: core: fix race condition against transaction listTakashi Sakamoto1-9/+10
The list of transaction is enumerated without acquiring card lock when processing AR response event. This causes a race condition bug when processing AT request completion event concurrently. This commit fixes the bug by put timer start for split transaction expiration into the scope of lock. The value of jiffies in card structure is referred before acquiring the lock. Cc: stable@vger.kernel.org # v6.18 Fixes: b5725cfa4120 ("firewire: core: use spin lock specific to timer for split transaction") Reported-by: Andreas Persson <andreasp56@outlook.com> Closes: https://github.com/alsa-project/snd-firewire-ctl-services/issues/209 Tested-by: Andreas Persson <andreasp56@outlook.com> Link: https://lore.kernel.org/r/20260127223413.22265-1-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2026-01-28drm/amdgpu: Fix cond_exec handling in amdgpu_ib_schedule()Alex Deucher1-2/+3
The EXEC_COUNT field must be > 0. In the gfx shadow handling we always emit a cond_exec packet after the gfx_shadow packet, but the EXEC_COUNT never gets patched. This leads to a hang when we try and reset queues on gfx11 APUs. Fixes: c68cbbfd54c6 ("drm/amdgpu: cleanup conditional execution") Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4789 Reviewed-by: Jesse Zhang <Jesse.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit ba205ac3d6e83f56c4f824f23f1b4522cb844ff3) Cc: stable@vger.kernel.org
2026-01-28drm/amdgpu/soc21: fix xclk for APUsAlex Deucher1-1/+7
The reference clock is supposed to be 100Mhz, but it appears to actually be slightly lower (99.81Mhz). Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/14451 Reviewed-by: Jesse Zhang <Jesse.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 637fee3954d4bd509ea9d95ad1780fc174489860) Cc: stable@vger.kernel.org
2026-01-28cpufreq: ondemand: Simplify idle cputime granularity testFrederic Weisbecker1-6/+1
cpufreq calls get_cpu_idle_time_us() just to know if idle cputime accounting has a nanoseconds granularity. Use the appropriate indicator instead to make that deduction. Signed-off-by: Frederic Weisbecker <frederic@kernel.org> Link: https://patch.msgid.link/aXozx0PXutnm8ECX@localhost.localdomain Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-01-28cpufreq: userspace: make scaling_setspeed return the actual requested frequencyPengjie Zhang1-1/+3
According to the Linux kernel ABI documentation for 'scaling_setspeed': "It returns the last frequency requested by the governor (in kHz) or can be written to in order to set a new frequency for the policy." However, the current implementation of show_speed() returns 'policy->cur'. 'policy->cur' represents the frequency after the driver has resolved the request against the hardware frequency table and applied policy limits (min/max). This creates a discrepancy between the documentation/user expectation and the actual code behavior. For instance: 1. User writes a value to 'scaling_setspeed' that is not in the OPP table (e.g., user asks for A, driver rounds it to B). 2. User reads 'scaling_setspeed'. 3. Code returns B ('policy->cur'). 4. User expects A (the "frequency requested"), but gets B. This patch changes show_speed() to return 'userspace->setspeed', which stores the actual value last requested by the user. This restores the read/write symmetry of the attribute and aligns the code with the ABI description. The effective frequency can still be observed via 'scaling_cur_freq' or 'cpuinfo_cur_freq', preserving the distinction between "what was requested" (setspeed) and "what is effective" (cur_freq). Signed-off-by: Pengjie Zhang <zhangpengjie2@huawei.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: lihuisong@huawei.com Link: https://patch.msgid.link/20260116094623.2980031-1-zhangpengjie2@huawei.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-01-28drm/amdgpu: Fix cond_exec handling in amdgpu_ib_schedule()Alex Deucher1-2/+3
The EXEC_COUNT field must be > 0. In the gfx shadow handling we always emit a cond_exec packet after the gfx_shadow packet, but the EXEC_COUNT never gets patched. This leads to a hang when we try and reset queues on gfx11 APUs. Fixes: c68cbbfd54c6 ("drm/amdgpu: cleanup conditional execution") Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4789 Reviewed-by: Jesse Zhang <Jesse.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-01-28drm/amdgpu/soc21: fix xclk for APUsAlex Deucher1-1/+7
The reference clock is supposed to be 100Mhz, but it appears to actually be slightly lower (99.81Mhz). Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/14451 Reviewed-by: Jesse Zhang <Jesse.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-01-28drm/amdkfd: gfx12.1 trap handler instruction fixup for VOP3PXJay Cornwall2-101/+121
A trap may occur in the middle of VOP3PX instruction co-issue. The PC would be restored incorrectly if left unmodified. Identify this case by examining the instruction opcode and rewind the PC 8 bytes if it occurs. Signed-off-by: Jay Cornwall <jay.cornwall@amd.com> Reviewed-by: Lancelot Six <lancelot.six@amd.com> Reviewed-by: Vladimir Indic <vladimir.indic@amd.com> Cc: Shweta Khatri <shweta.khatri@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-01-28drm/amd/pm: Fix null pointer dereference issueJinzhou Su1-0/+3
If SMU is disabled, during RAS initialization, there will be null pointer dereference issue here. Signed-off-by: Jinzhou Su <jinzhou.su@amd.com> Reviewed-by: Yang Wang <kevinyang.wang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-01-28thermal/of: Fix reference leak in thermal_of_cm_lookup()Felix Gu1-2/+2
In thermal_of_cm_lookup(), tr_np is obtained via of_parse_phandle(), but never released. Use the __free(device_node) cleanup attribute to automatically release the node and fix the leak. Fixes: 423de5b5bc5b ("thermal/of: Fix cdev lookup in thermal_of_should_bind()") Signed-off-by: Felix Gu <ustc.gu@gmail.com> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> [ rjw: Changelog edits ] Link: https://patch.msgid.link/20260124-thermal_of-v1-1-54d3416948cf@gmail.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-01-28thermal: core: thermal_core.h: fix all kernel-doc warningsRandy Dunlap1-2/+5
Resolve all kernel-doc warnings in thermal_core.h: Warning: drivers/thermal/thermal_core.h:99 bad line: trip point. Warning: drivers/thermal/thermal_core.h:101 bad line: passive trip point. Warning: drivers/thermal/thermal_core.h:152 struct member 'trips_attribute_group' not described in 'thermal_zone_device' Warning: drivers/thermal/thermal_core.h:152 struct member 'debugfs' not described in 'thermal_zone_device' Warning: drivers/thermal/thermal_core.h:152 struct member 'user_thresholds' not described in 'thermal_zone_device' Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Link: https://patch.msgid.link/20260128062446.402175-1-rdunlap@infradead.org Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-01-28ACPI: scan: Use async schedule function in acpi_scan_clear_dep_fn()Yicong Yang1-26/+15
The device object rescan in acpi_scan_clear_dep_fn() is scheduled on a system workqueue which is not guaranteed to be finished before entering userspace. This may cause some key devices to be missing when userspace init task tries to find them. Two issues observed on RISCV platforms: - Kernel panic due to userspace init cannot have an opened console. The console device scanning is queued by acpi_scan_clear_dep_queue() and not finished by the time userspace init process running, thus by the time userspace init runs, no console is present. - Entering rescue shell due to the lack of root devices (PCIe nvme in our case). Same reason as above, the PCIe host bridge scanning is queued on a system workqueue and finished after init process runs. The reason is because both devices (console, PCIe host bridge) depend on riscv-aplic irqchip to serve their interrupts (console's wired interrupt and PCI's INTx interrupts). In order to keep the dependency, these devices are scanned and created after initializing riscv-aplic. The riscv-aplic is initialized in device_initcall() and a device scan work is queued via acpi_scan_clear_dep_queue(), which is close to the time userspace init process is run. Since system_dfl_wq is used in acpi_scan_clear_dep_queue() with no synchronization, the issues will happen if userspace init runs before these devices are ready. The solution is to wait for the queued work to complete before entering userspace init. One possible way would be to use a dedicated workqueue instead of system_dfl_wq, and explicitly flush it somewhere in the initcall stage before entering userspace. Another way is to use async_schedule_dev_nocall() for scanning these devices. It's designed for asynchronous initialization and will work in the same way as before because it's using a dedicated unbound workqueue as well, but the kernel init code calls async_synchronize_full() right before entering userspace init which will wait for the work to complete. Compared to a dedicated workqueue, the second approach is simpler because the async schedule framework takes care of all of the details. The ACPI code only needs to focus on its job. A dedicated workqueue for this could also be redundant because some platforms don't need acpi_scan_clear_dep_queue() for their device scanning. Signed-off-by: Yicong Yang <yang.yicong@picoheart.com> [ rjw: Subject adjustment, changelog edits ] Link: https://patch.msgid.link/20260128132848.93638-1-yang.yicong@picoheart.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-01-28ACPI: x86: s2idle: Invoke Microsoft _DSM Function 9 (Turn On Display)Jakob Riemenschneider1-0/+6
Windows 11, version 22H2 introduced a new function index (Function 9) to the Microsoft LPS0 _DSM, titled "Turn On Display Notification". According to Microsoft documentation, this function signals to the system firmware that the OS intends to turn on the display when exiting Modern Standby. This allows the firmware to release Power Limits (PLx) earlier. Crucially, this patch fixes a functional issue observed on the Lenovo Yoga Slim 7i Aura (15ILL9), where system fans and keyboard backlights fail to resume after suspend. Investigation linked shows the EC on this device turns off these components during sleep but requires the Function 9 notification to wake them up again. This patch defines the new function index (ACPI_MS_TURN_ON_DISPLAY) and invokes it in acpi_s2idle_restore_early_lps0(). The execution order is updated to match the logic of an "intent" signal: 1. LPS0 Exit (Function 6) 2. Turn On Display Intent (Function 9) 3. Modern Standby Exit (Function 8) 4. Screen On (Function 4) Invoking Function 9 before the Modern Standby Exit ensures the firmware has time to restore power rails and functionality (like fans) before the software fully exits the sleep state. Link: https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/modern-standby-firmware-notifications#turn-on-display-notification-function-9 Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220505 Suggested-by: Antheas Kapenekakis <antheas@antheas.dev> Signed-off-by: Jakob Riemenschneider <riemenschneiderjakob@gmail.com> Link: https://patch.msgid.link/20260127200121.1292216-1-riemenschneiderjakob@gmail.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-01-28spi: cadence-qspi: Use a default value for cdns,fifo-widthMiquel Raynal (Schneider Electric)1-4/+2
Bindings expect 4 to be the default value for cdns,fifo-width. Said otherwise, if the property (which is not mandatory) is not provided, the OS, in order to comply with the bindings, should not error out and take 4 as default value. Comply with the bindings. This would have slighlty simplyfied my testing if it had been implemented correctly in the first place, but in practice it should have no impact on the existing boards using this controller, as they all set cdns,fifo-width to 4 explicitly in their upstream DTS. Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Miquel Raynal (Schneider Electric) <miquel.raynal@bootlin.com> Tested-by: Santhosh Kumar K <s-k6@ti.com> Link: https://patch.msgid.link/20260122-schneider-6-19-rc1-qspi-v4-13-f9c21419a3e6@bootlin.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-28spi: cadence-qspi: Make sure write protection is disabledMiquel Raynal (Schneider Electric)1-0/+7
Renesas RZ/N1 QSPI controllers embed the Cadence IP with some modifications. For instance, they feature a write protection of the direct mapping at the controller level, with this feature all data writes to the AHB region are aborted. Despite the fact that the flag setting write protection is disabled by default, Bootloaders may (and actually do) set it, so mark this feature as being available with a specific flag to, if applicable, make sure it is disabled. Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Miquel Raynal (Schneider Electric) <miquel.raynal@bootlin.com> Tested-by: Santhosh Kumar K <s-k6@ti.com> Link: https://patch.msgid.link/20260122-schneider-6-19-rc1-qspi-v4-12-f9c21419a3e6@bootlin.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-28spi: cadence-qspi: Add a flag for controllers without indirect access supportMiquel Raynal (Schneider Electric)1-13/+16
Renesas RZ/N1 QSPI controllers embed the Cadence IP with some limitations/simplifications. One of the is that only direct access is supported, none of the registers related to indirect writes are populated, so create a flag to avoid these accesses and make sure only direct accessors are called. Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Miquel Raynal (Schneider Electric) <miquel.raynal@bootlin.com> Tested-by: Santhosh Kumar K <s-k6@ti.com> Link: https://patch.msgid.link/20260122-schneider-6-19-rc1-qspi-v4-11-f9c21419a3e6@bootlin.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-28spi: cadence-qspi: Try hard to disable the clocksMiquel Raynal (Schneider Electric)1-2/+5
In the remove path, we should try hard to perform all steps as we simply cannot fail. The "no runtime PM" quirk must only alter the state of the RPM core, but the clocks should still be disabled if that is possible. Move the disable call outside of the RPM quirk. Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Miquel Raynal (Schneider Electric) <miquel.raynal@bootlin.com> Tested-by: Santhosh Kumar K <s-k6@ti.com> Link: https://patch.msgid.link/20260122-schneider-6-19-rc1-qspi-v4-9-f9c21419a3e6@bootlin.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-28spi: cadence-qspi: Fix probe error path and removeMiquel Raynal (Schneider Electric)1-19/+25
The probe has been modified by many different users, it is hard to track history, but for sure its current state is partially broken. One easy rule to follow is to drop/free/release the resources in the opposite order they have been queried. Fix the labels, the order for freeing the resources, and add the missing DMA channel step. Replicate these changes in the remove path as well. Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Miquel Raynal (Schneider Electric) <miquel.raynal@bootlin.com> Tested-by: Santhosh Kumar K <s-k6@ti.com> Link: https://patch.msgid.link/20260122-schneider-6-19-rc1-qspi-v4-8-f9c21419a3e6@bootlin.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-28spi: cadence-qspi: Make sure we filter out unsupported opsMiquel Raynal (Schneider Electric)1-0/+4
The Cadence driver does not support anything else than repeating the command opcode twice while in octal DTR mode. Make this clear by checking for this in the ->supports_op() hook. Reviewed-by: Pratyush Yadav <pratyush@kernel.org> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Miquel Raynal (Schneider Electric) <miquel.raynal@bootlin.com> Tested-by: Santhosh Kumar K <s-k6@ti.com> Link: https://patch.msgid.link/20260122-schneider-6-19-rc1-qspi-v4-7-f9c21419a3e6@bootlin.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-28spi: cadence-qspi: Remove an useless operationMiquel Raynal (Schneider Electric)1-1/+1
Right above writing the register value back based on 'div' value, there is the following check: if (div > CQSPI_REG_CONFIG_BAUD_MASK) div = CQSPI_REG_CONFIG_BAUD_MASK; which means div does not need to be AND'ed against the bitfield mask. Remove this redundant operation. Reviewed-by: Pratyush Yadav <pratyush@kernel.org> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Miquel Raynal (Schneider Electric) <miquel.raynal@bootlin.com> Tested-by: Santhosh Kumar K <s-k6@ti.com> Link: https://patch.msgid.link/20260122-schneider-6-19-rc1-qspi-v4-6-f9c21419a3e6@bootlin.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-28spi: cadence-qspi: Fix ORing style and alignmentsMiquel Raynal (Schneider Electric)1-11/+8
These definitions do not follow the standard patterns. Alignments are incoherent and the logical OR symbols '|' are misplaced. Reorganize these definitions. There is no functional change. Acked-by: Pratyush Yadav <pratyush@kernel.org> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Miquel Raynal (Schneider Electric) <miquel.raynal@bootlin.com> Tested-by: Santhosh Kumar K <s-k6@ti.com> Link: https://patch.msgid.link/20260122-schneider-6-19-rc1-qspi-v4-5-f9c21419a3e6@bootlin.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-28spi: cadence-qspi: Fix style and improve readabilityMiquel Raynal (Schneider Electric)1-10/+5
It took me several seconds to correctly understand this block. I understand the goal: showing that we are in the if, or in one of the two other cases. Improve the organization of the code to both improve readability and fix the style. Suggested-by: Pratyush Yadav <pratyush@kernel.org> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Miquel Raynal (Schneider Electric) <miquel.raynal@bootlin.com> Tested-by: Santhosh Kumar K <s-k6@ti.com> Link: https://patch.msgid.link/20260122-schneider-6-19-rc1-qspi-v4-4-f9c21419a3e6@bootlin.com Signed-off-by: Mark Brown <broonie