summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-12-18spi: atcspi200: Add support for Andes ATCSPI200 SPIMark Brown
Merge series from CL Wang <cl634@andestech.com>: This series adds support for the Andes ATCSPI200 SPI controller.
2025-12-18test-ww_mutex: Allow test to be run (and re-run) from userlandJohn Stultz
In cases where the ww_mutex test was occasionally tripping on hard to find issues, leaving qemu in a reboot loop was my best way to reproduce problems. These reboots however wasted time when I just wanted to run the test-ww_mutex logic. So tweak the test-ww_mutex test so that it can be re-triggered via a sysfs file, so the test can be run repeatedly without doing module loads or restarting. This has been particularly valuable to stressing and finding issues with the proxy-exec series. To use, run as root: echo 1 > /sys/kernel/test_ww_mutex/run_tests Signed-off-by: John Stultz <jstultz@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20251205013515.759030-4-jstultz@google.com
2025-12-18test-ww_mutex: Move work to its own UNBOUND workqueueJohn Stultz
The test-ww_mutex test already allocates its own workqueue so be sure to use it for the mtx.work and abba.work rather then the default system workqueue. This resolves numerous messages of the sort: "workqueue: test_abba_work hogged CPU... consider switching to WQ_UNBOUND" "workqueue: test_mutex_work hogged CPU... consider switching to WQ_UNBOUND" Signed-off-by: John Stultz <jstultz@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20251205013515.759030-3-jstultz@google.com
2025-12-18test-ww_mutex: Extend ww_mutex tests to test both classes of ww_mutexesJohn Stultz
Currently the test-ww_mutex tool only utilizes the wait-die class of ww_mutexes, and thus isn't very helpful in exercising the wait-wound class of ww_mutexes. So extend the test to exercise both classes of ww_mutexes for all of the subtests. Signed-off-by: John Stultz <jstultz@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20251205013515.759030-2-jstultz@google.com
2025-12-18entry: Always inline local_irq_{enable,disable}_exit_to_user()Eric Dumazet
clang needs __always_inline instead of inline, even for tiny helpers. This saves some cycles in system call fast path, and saves 195 bytes on x86_64 build: $ size vmlinux.before vmlinux.after text data bss dec hex filename 34652814 22291961 5875180 62819955 3be8e73 vmlinux.before 34652619 22291961 5875180 62819760 3be8db0 vmlinux.after Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20251204153127.1321824-1-edumazet@google.com
2025-12-18drm/syncobj: Convert syncobj idr to xarrayTvrtko Ursulin
IDR is deprecated and syncobj looks pretty trivial to convert so lets just do it. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: intel-xe@lists.freedesktop.org Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20251205150910.92913-1-tvrtko.ursulin@igalia.com
2025-12-18spi: cadence-quadspi: Fix probe error path and loggingMark Brown
Merge series from Anurag Dutta <a-dutta@ti.com>: This series addresses issues in the cadence-quadspi driver's probe error path: Patch 1 fixes a clock disable imbalance that occurs when probe fails after runtime PM is enabled, particularly when DMA request returns -EPROBE_DEFER. Patch 2 adds proper error logging for DMA request failures using dev_err_probe() to improve diagnostics and handle probe deferral appropriately. logs : https://gist.github.com/anuragdutta731/59925cd11a50913b7128c88cd5394db7
2025-12-18PCI: dw-rockchip: Change get_ltssm() to provide L1 Substates infoShawn Lin
Rename rockchip_pcie_get_ltssm() to rockchip_pcie_get_ltssm_reg() and add rockchip_pcie_get_ltssm() to get_ltssm() callback in order to show the proper L1 Substates. The PCIE_CLIENT_LTSSM_STATUS[5:0] register returns the same LTSSM layout as enum dw_pcie_ltssm. So the driver just need to convey L1 PM Substates by returning the proper value defined in pcie-designware.h. cat /sys/kernel/debug/dwc_pcie_a40000000.pcie/ltssm_status L1_2 (0x142) Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/1765503205-22184-2-git-send-email-shawn.lin@rock-chips.com
2025-12-18PCI: dwc: Add L1 Substates context to ltssm_status of debugfsShawn Lin
DWC core couldn't distinguish LTSSM state among L1.0, L1.1 and L1.2. But the vendor glue driver may implement additional logic to convey this information. So add two pseudo definitions for vendor glue drivers to translate their internal L1 Substates for debugfs to show. Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/1765503205-22184-1-git-send-email-shawn.lin@rock-chips.com
2025-12-18Add support for NXP XSPIMark Brown
Merge series from Haibo Chen <haibo.chen@nxp.com>: XSPI is a flexible SPI host controller which supports up to 2 external devices (2 CS). It support Single/Dual/Quad/Octal mode data transfer. The difference between XSPI and Flexspi is XSPI support multiple independent execution environments (EENVs) for HW virtualization with some limitations. Each EENV has its own interrupt and its own set of programming registers that exists in a specific offset range in the XSPI memory map. The main environment (EENV0) address space contains all of the registers for controlling EENV0 plus all of the general XSPI control and programming registers. The register mnemonics for the user environments (EENV1 to EENV4) have "_SUB_n" appended to the mnemonic for the corresponding main-environment register. Current driver based on EENV0, which means system already give EENV0 right to linux. This driver use SPI memory interface of the SPI framework to issue flash memory operations. Tested this driver with mtd_debug and UBIFS on NXP i.MX943 EVK board which has one MT35XU512ABA spi nor flash. NOw this driver has the following key features: - Support up to OCT DDR mode - Support AHB read - Support IP read and IP write - Support two CS
2025-12-18ASoC: codec: rt286: Use devm_request_threaded_irq to manage IRQ lifetime and ↵HariKrishna Sagala
fix smatch warning Replace manual "request_threaded_irq()" with the device managed "devm_request_threaded_irq" to manage the IRQ lifetime and also it removes the smatch reported warning. Remove the manual "free_irq()" in the "remove" function as free_irq is tied to device teardown. Signed-off-by: HariKrishna Sagala <hariconscious@gmail.com> Link: https://patch.msgid.link/20251217054458.38257-2-hariconscious@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-18ASoC: tas2783A: read slave properties from acpi tableNiranjan H Y
Currently device is using hardcoded slave properties using the .read_prop callback from "struct sdw_slave_ops". This patch removes this and uses the sdw_slave_read_prop API to read the data directly from the ACPI table. Signed-off-by: Niranjan H Y <niranjan.hy@ti.com> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20251215153219.810-8-niranjan.hy@ti.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-18ASoC: tas2783A: use acpi initialisation tableNiranjan H Y
This patch adds support for parsing the initilisation data from ACPI table. This table is required to configure each device correctly so that correct channel's data is selected during playback. Signed-off-by: Niranjan H Y <niranjan.hy@ti.com> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20251215153219.810-7-niranjan.hy@ti.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-18ASoc: tas2783A: acpi match for 4 channel for mtlNiranjan H Y
Add changes to support 4 tas2783A devices on mtl platform. The supported unique IDs are updated to 9, a, c, d, where c and d are configured to play left channels and 9 and a are configured to play right channel. Signed-off-by: Niranjan H Y <niranjan.hy@ti.com> Link: https://patch.msgid.link/20251215153219.810-6-niranjan.hy@ti.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-18ASoc: tas2783A: fw name based on system detailsNiranjan H Y
The firmware file for tas2783A contains the device and algorithm settings. So the firmware files are unique for a system and driver should have the ability to distinctly identify and pick the right firmware. This commit adds the method to uniquely identify the firmware for a system based on the below format. <Subsystem>-<Link>-<Unique>.bin * Subsystem is the PCI device subsystem-id * Link is the SoundWire link id on which the device recides. * Unique is the SoundWire slave unique id in the system. Signed-off-by: Niranjan H Y <niranjan.hy@ti.com> Link: https://patch.msgid.link/20251215153219.810-5-niranjan.hy@ti.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-18ASoC: tas2783A: fix error log for calibration dataNiranjan H Y
Currently when the calibration is not found, it is wrongly logged as device is not found. Fix this error message to indicate that calibration data is not valid instead. Signed-off-by: Niranjan H Y <niranjan.hy@ti.com> Link: https://patch.msgid.link/20251215153219.810-4-niranjan.hy@ti.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-18ASoC: tas2783A: update default init writesNiranjan H Y
Remove unwanted initialistaion writes to the device which will now be part of the either firmware or acpi table. Signed-off-by: Niranjan H Y <niranjan.hy@ti.com> Link: https://patch.msgid.link/20251215153219.810-3-niranjan.hy@ti.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-18ASoC: tas2783A: use custom firmwareNiranjan H Y
Use the firmware version same as in Windows projects. The firmware contains algorithm parameters and some device configuration writes which are part of the same firmware file. Signed-off-by: Niranjan H Y <niranjan.hy@ti.com> Link: https://patch.msgid.link/20251215153219.810-2-niranjan.hy@ti.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-18ASoC: tas2783A: sdw_utils: support ch 3 & 4Niranjan H Y
Currently the machine driver for tas2783A can only support 2 channels. This patch adds support for 2 channel playback with 4 device setup. Signed-off-by: Niranjan H Y <niranjan.hy@ti.com> Link: https://patch.msgid.link/20251215153219.810-1-niranjan.hy@ti.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-18rust: drm: use `pin_init::zeroed()` for file operations initializationAtharv Dubey
Replace the manual `unsafe { core::mem::zeroed() }` initialization of `bindings::file_operations` with `pin_init::zeroed()`. This removes the explicit unsafe Signed-off-by: Atharv Dubey <atharvd440@gmail.com> Link: https://patch.msgid.link/20251201152759.16429-1-atharvd440@gmail.com Signed-off-by: Alice Ryhl <aliceryhl@google.com>
2025-12-18PCI: mediatek: Fix IRQ domain leak when MSI allocation failsHaotian Zhang
In mtk_pcie_init_irq_domain(), if mtk_pcie_allocate_msi_domains() fails after port->irq_domain has been successfully created via irq_domain_create_linear(), the function returns directly without cleaning up the allocated IRQ domain, resulting in a resource leak. Add irq_domain_remove() call in the error path to properly release the INTx IRQ domain before returning the error. Fixes: 43e6409db64d ("PCI: mediatek: Add MSI support for MT2712 and MT7622") Signed-off-by: Haotian Zhang <vulab@iscas.ac.cn> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20251119023308.476-1-vulab@iscas.ac.cn
2025-12-18can: fix build dependencyMarc Kleine-Budde
Arnd Bergmann's patch [1] fixed the build dependency problem introduced by bugfix commit cb2dc6d2869a ("can: Kconfig: select CAN driver infrastructure by default"). This ended up as commit 6abd4577bccc ("can: fix build dependency"), but I broke Arnd's fix by removing a dependency that we thought was superfluous. [1] https://lore.kernel.org/all/20251204100015.1033688-1-arnd@kernel.org/ Meanwhile the problem was also found by intel's kernel test robot, complaining about undefined symbols: | ERROR: modpost: "m_can_class_unregister" [drivers/net/can/m_can/m_can_platform.ko] undefined! | ERROR: modpost: "m_can_class_free_dev" [drivers/net/can/m_can/m_can_platform.ko] undefined! | ERROR: modpost: "m_can_class_allocate_dev" [drivers/net/can/m_can/m_can_platform.ko] undefined! | ERROR: modpost: "m_can_class_get_clocks" [drivers/net/can/m_can/m_can_platform.ko] undefined! | ERROR: modpost: "m_can_class_register" [drivers/net/can/m_can/m_can_platform.ko] undefined! To fix this problem, add the missing dependency again. Cc: Vincent Mailhol <mailhol@kernel.org> Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202512132253.vO9WFDJK-lkp@intel.com/ Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202512180808.fTAUQ2XN-lkp@intel.com/ Reported-by: Arnd Bergmann <arnd@arndb.de> Closes: https://lore.kernel.org/all/7427949a-ea7d-4854-9fe4-e01db7d878c7@app.fastmail.com/ Fixes: 6abd4577bccc ("can: fix build dependency") Fixes: cb2dc6d2869a ("can: Kconfig: select CAN driver infrastructure by default") Acked-by: Vincent Mailhol <mailhol@kernel.org> Link: https://patch.msgid.link/20251217-can-fix-dependency-v1-1-fd2d4f2a2bf5@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-12-18PCI: j721e: Add config guards for Cadence Host and Endpoint library APIsSiddharth Vadapalli
Commit under Fixes enabled loadable module support for the driver under the assumption that it shall be the sole user of the Cadence Host and Endpoint library APIs. This assumption guarantees that we won't end up in a case where the driver is built-in and the library support is built as a loadable module. With the introduction of [1], this assumption is no longer valid. The SG2042 driver could be built as a loadable module, implying that the Cadence Host library is also selected as a loadable module. However, the pci-j721e.c driver could be built-in as indicated by CONFIG_PCI_J721E=y due to which the Cadence Endpoint library is built-in. Despite the library drivers being built as specified by their respective consumers, since the 'pci-j721e.c' driver has references to the Cadence Host library APIs as well, we run into a build error as reported at [0]. Fix this by adding config guards as a temporary workaround. The proper fix is to split the 'pci-j721e.c' driver into independent Host and Endpoint drivers as aligned at [2]. [0]: https://lore.kernel.org/r/202511111705.MZ7ls8Hm-lkp@intel.com/ [1]: commit 1c72774df028 ("PCI: sg2042: Add Sophgo SG2042 PCIe driver") [2]: https://lore.kernel.org/r/37f6f8ce-12b2-44ee-a94c-f21b29c98821@app.fastmail.com/ Fixes: a2790bf81f0f ("PCI: j721e: Add support to build as a loadable module") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202511111705.MZ7ls8Hm-lkp@intel.com/ Suggested-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20251117113246.1460644-1-s-vadapalli@ti.com
2025-12-18rust: drm: Update AlwaysRefCounted imports to use sync::arefShankari Anand
Update call sites to import `AlwaysRefCounted` from `sync::aref` instead of `types`. This aligns with the ongoing effort to move `ARef` and `AlwaysRefCounted` to sync. Suggested-by: Benno Lossin <lossin@kernel.org> Link: https://github.com/Rust-for-Linux/linux/issues/1173 Signed-off-by: Shankari Anand <shankari.ak0208@gmail.com> Link: https://patch.msgid.link/20251123092438.182251-5-shankari.ak0208@gmail.com Signed-off-by: Alice Ryhl <aliceryhl@google.com>
2025-12-18drivers: gpu: Update ARef imports from sync::arefShankari Anand
Update call sites to import `ARef` from `sync::aref` instead of `types`. This aligns with the ongoing effort to move `ARef` and `AlwaysRefCounted` to sync. Suggested-by: Benno Lossin <lossin@kernel.org> Link: https://github.com/Rust-for-Linux/linux/issues/1173 Signed-off-by: Shankari Anand <shankari.ak0208@gmail.com> Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com> Acked-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20251123092438.182251-3-shankari.ak0208@gmail.com [aliceryhl: keep trailing // at last import] Signed-off-by: Alice Ryhl <aliceryhl@google.com>
2025-12-18PCI: qcom: Remove DPC Extended CapabilityQiang Yu
Some platforms (e.g., X1E80100) expose Downstream Port Containment (DPC) Extended Capability registers in the PCIe Root Port config space, but do not fully support it. To prevent undefined behavior and ensure DPC cap is not visible to PCI framework and users, remove DPC Extended Capability unconditionally, since there is no Qcom platform support DPC till now. Co-developed-by: Wenbin Yao <wenbin.yao@oss.qualcomm.com> Signed-off-by: Wenbin Yao <wenbin.yao@oss.qualcomm.com> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20251109-remove_cap-v1-5-2208f46f4dc2@oss.qualcomm.com
2025-12-18PCI: qcom: Remove MSI-X Capability for Root PortsQiang Yu
On some platforms like Glymur, the hardware does not support MSI-X in RC mode, yet still exposes the MSI-X capability. However, it omits the required MSI-X Table and PBA structures. This mismatch can lead to issues where the PCIe port driver requests MSI-X instead of MSI, causing the Root Port to trigger interrupts by writing to an uninitialized address, resulting in SMMU faults. To address this, remove MSI-X capability unconditionally for Root Ports of all SoCs as none of the Qcom PCIe Root Ports support MSI-X. Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com> [mani: updated description] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20251109-remove_cap-v1-4-2208f46f4dc2@oss.qualcomm.com
2025-12-18PCI: dwc: Remove MSI/MSIX capability for Root Port if iMSI-RX is used as MSI ↵Qiang Yu
controller Some platforms may not support ITS (Interrupt Translation Service) and MBI (Message Based Interrupt), or there are not enough available empty SPI lines for MBI, in which case the msi-map and msi-parent property will not be provided in device tree node. For those cases, the DWC PCIe driver defaults to using the iMSI-RX module as MSI controller. However, due to DWC IP design, iMSI-RX cannot generate MSI interrupts for Root Ports even when MSI is properly configured and supported as iMSI-RX will only monitor and intercept incoming MSI TLPs from PCIe link, but the memory write generated by Root Port are internal system bus transactions instead of PCIe TLPs, so they are ignored. This leads to interrupts such as PME, AER from the Root Port not received on the host and the users have to resort to workarounds such as passing "pcie_pme=nomsi" cmdline parameter. To ensure reliable interrupt handling, remove MSI and MSI-X capabilities from Root Ports when using iMSI-RX as MSI controller, which is indicated by 'dw_pcie_rp::has_msi_ctrl == true'. This forces a fallback to INTx interrupts by default, eliminating the need for manual kernel command line workarounds. With this behavior: - Platforms with ITS/MBI support use ITS/MBI MSI for interrupts from all components. - Platforms without ITS/MBI support fall back to INTx for Root Ports and use iMSI-RX for other PCI devices. Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com> [mani: reworded the comment] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Tested-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Brian Norris <briannorris@chromium.org> Link: https://patch.msgid.link/20251109-remove_cap-v1-3-2208f46f4dc2@oss.qualcomm.com
2025-12-18PCI: dwc: Add new APIs to remove standard and extended CapabilityQiang Yu
On some platforms, certain PCIe Capabilities may be present in hardware but are not fully implemented as defined in PCIe spec. These incomplete capabilities should be hidden from the PCI framework to prevent unexpected behavior. Introduce two APIs to remove a specific PCIe Capability and Extended Capability by updating the previous capability's next offset field to skip over the unwanted capability. These APIs allow RC drivers to easily hide unsupported or partially implemented capabilities from software. Co-developed-by: Wenbin Yao <wenbin.yao@oss.qualcomm.com> Signed-off-by: Wenbin Yao <wenbin.yao@oss.qualcomm.com> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20251109-remove_cap-v1-2-2208f46f4dc2@oss.qualcomm.com
2025-12-18PCI: Add preceding capability position support in PCI_FIND_NEXT_*_CAP macrosQiang Yu
Add support for finding the preceding capability position in PCI capability list by extending the capability finding macros with an additional parameter. This functionality is essential for modifying PCI capability list, as it provides the necessary information to update the "next" pointer of the predecessor capability when removing entries. Modify two macros to accept a new 'prev_ptr' parameter: - PCI_FIND_NEXT_CAP - Now accepts 'prev_ptr' parameter for standard capabilities - PCI_FIND_NEXT_EXT_CAP - Now accepts 'prev_ptr' parameter for extended capabilities When a capability is found, these macros: - Store the position of the preceding capability in *prev_ptr (if prev_ptr != NULL) - Maintain all existing functionality when prev_ptr is NULL Update current callers to accommodate this API change by passing NULL to 'prev_ptr' argument if they do not care about the preceding capability position. No functional changes to driver behavior result from this commit as it maintains the existing capability finding functionality while adding the infrastructure for future capability removal operations. Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20251109-remove_cap-v1-1-2208f46f4dc2@oss.qualcomm.com
2025-12-18PCI: rcar-host: Add OF Kconfig dependency to avoid objtool no-cfi warningNathan Chancellor
After commit 894af4a1cde6 ("objtool: Validate kCFI calls"), compile testing pcie-rcar-host.c with CONFIG_FINEIBT=y and CONFIG_OF=n results in a no-cfi objtool warning in rcar_pcie_probe(): $ cat allno.config CONFIG_CFI=y CONFIG_COMPILE_TEST=y CONFIG_CPU_MITIGATIONS=y CONFIG_GENERIC_PHY=y CONFIG_MITIGATION_RETPOLINE=y CONFIG_MODULES=y CONFIG_PCI=y CONFIG_PCI_MSI=y CONFIG_PCIE_RCAR_HOST=y CONFIG_X86_KERNEL_IBT=y $ make -skj"$(nproc)" ARCH=x86_64 KCONFIG_ALLCONFIG=1 LLVM=1 clean allnoconfig vmlinux vmlinux.o: warning: objtool: rcar_pcie_probe+0x191: no-cfi indirect call! When CONFIG_OF is unset, of_device_get_match_data() returns NULL, so LLVM knows this indirect call has no valid destination and drops the kCFI setup before the call, triggering the objtool check that makes sure all indirect calls have kCFI setup. This driver depends on OF for probing with non-NULL data for every match so this call will never be NULL in practice. Add a hard Kconfig dependency on OF to avoid the warning. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202510092124.O2IX0Jek-lkp@intel.com/ Closes: https://github.com/ClangBuiltLinux/linux/issues/2134 Signed-off-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20251014-rcar_pcie_probe-avoid-nocfi-objtool-warning-v2-1-6e0204b002c6@kernel.org
2025-12-18Merge tag 'amd-drm-fixes-6.19-2025-12-17' of ↵Dave Airlie
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes amd-drm-fixes-6.19-2025-12-17: amdgpu: - Fix no_console_suspend handling - DCN 3.5.x seamless boot fixes - DP audio fix - Fix race in GPU recovery - SMU 14 OD fix amdkfd: - Event fix Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patch.msgid.link/20251217171821.2033671-1-alexander.deucher@amd.com
2025-12-17drm/xe/eustall: Disallow 0 EU stall property valuesAshutosh Dixit
An EU stall property value of 0 is invalid and will cause a NPD. Reported-by: Peter Senna Tschudin <peter.senna@linux.intel.com> Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6453 Fixes: 1537ec85ebd7 ("drm/xe/uapi: Introduce API for EU stall sampling") Cc: stable@vger.kernel.org Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by: Harish Chegondi <harish.chegondi@intel.com> Link: https://patch.msgid.link/20251212061850.1565459-4-ashutosh.dixit@intel.com
2025-12-17drm/xe/oa: Disallow 0 OA property valuesAshutosh Dixit
An OA property value of 0 is invalid and will cause a NPD. Reported-by: Peter Senna Tschudin <peter.senna@linux.intel.com> Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6452 Fixes: cc4e6994d5a2 ("drm/xe/oa: Move functions up so they can be reused for config ioctl") Cc: stable@vger.kernel.org Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by: Harish Chegondi <harish.chegondi@intel.com> Link: https://patch.msgid.link/20251212061850.1565459-3-ashutosh.dixit@intel.com
2025-12-17drm/xe/oa: Move default oa unit assignment earlier during stream openAshutosh Dixit
De-referencing param.oa_unit, when an OA unit id is not provided during stream open, results in NPD below. Oops: general protection fault, probably for non-canonical address... KASAN: null-ptr-deref in range... RIP: 0010:xe_oa_stream_open_ioctl+0x169/0x38a0 xe_observation_ioctl+0x19f/0x270 drm_ioctl_kernel+0x1f4/0x410 Fix this by moving default oa unit assignment before the dereference. Reported-by: Peter Senna Tschudin <peter.senna@linux.intel.com> Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6840 Fixes: c7e269aa565f ("drm/xe/oa: Allow exec_queue's to be specified only for OAG OA unit") Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by: Harish Chegondi <harish.chegondi@intel.com> Link: https://patch.msgid.link/20251212061850.1565459-2-ashutosh.dixit@intel.com
2025-12-17dt-bindings: sram: Document qcom,kaanapali-imem and its child nodeJingyi Wang
On Qualcomm Kaanapali platform, IMEM is a block of SRAM shared across multiple IP blocks which can falk back to "mmio-sram". Documnent it and its child node "qcom,pil-reloc-info" which is used for collecting remoteproc ramdumps. Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251123-knp-soc-binding-v4-1-42b349a66c59@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-12-17dt-bindings: interrupt-controller: qcom,pdc: Document Kaanapali Power Domain ↵Jingyi Wang
Controller Add a compatible for the Power Domain Controller on Kaanapali platforms. Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20251021-knp-pdc-v2-1-a38767f5bb8e@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-12-17arm64: dts: qcom: glymur: Add header file for IPCC physical client IDsSibi Sankar
Physical client IDs are used on Glymur Inter Process Communication Controller (IPCC), add a corresponding header file. Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20251031-knp-ipcc-v3-3-62ffb4168dff@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-12-17arm64: dts: qcom: kaanapali: Add header file for IPCC physical client IDsJingyi Wang
On earlier platforms, Inter Process Communication Controller (IPCC) used virtual client IDs and performed virtual-to-physical mapping in hardware, so the IDs defined in dt-bindings/mailbox/qcom-ipcc.h are common across platforms. Physical client IDs instead of virtual client IDs are used for qcom new platforms like Kaanapali, which will be parsed by the devicetree and passed to hardware to use Physical client IDs directly. Since physical client IDs could vary across platforms, add a corresponding header file for the Kaanapali platform. Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20251031-knp-ipcc-v3-2-62ffb4168dff@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-12-17dt-bindings: arm: qcom: Document Kaanapali SoC and its reference boardsJingyi Wang
Document the Kaanapali SoC binding and the boards which use it. Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251215-knp-dts-v4-1-1541bebeb89f@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-12-17clk: qcom: Add support for Global clock controller on KaanapaliTaniya Das
Add support for Global clock controller for Kaanapali Qualcomm SoC. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251209-gcc_kaanapali-v3-v5-4-3af118262289@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-12-17clk: qcom: Add TCSR clock driver for KaanapaliTaniya Das
Add the TCSR clock controller that provides the refclks on Kaanapali platform for PCIe, USB and UFS subsystems. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Abel Vesa <abel.vesa@linaro.org> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251209-gcc_kaanapali-v3-v5-3-3af118262289@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-12-17clk: qcom: rpmh: Add support for Kaanapali rpmh clocksTaniya Das
Add the RPMH clocks present in Kaanapali SoC. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251209-gcc_kaanapali-v3-v5-2-3af118262289@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-12-17clk: qcom: rpmh: Update the clock suffix for GlymurTaniya Das
The current RPMh VRM clock definitions do not accurately represent the hardware mapping of these clocks. While there is no functional impact, this update aligns the definitions with the hardware convention by adding the appropriate suffix to indicate the clock divider and the E0 variant for the C3A_E0, C4A_E0, C5A_E0, and C8A_E0 resources on Glymur. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251209-gcc_kaanapali-v3-v5-1-3af118262289@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-12-17ublk: fix deadlock when reading partition tableMing Lei
When one process(such as udev) opens ublk block device (e.g., to read the partition table via bdev_open()), a deadlock[1] can occur: 1. bdev_open() grabs disk->open_mutex 2. The process issues read I/O to ublk backend to read partition table 3. In __ublk_complete_rq(), blk_update_request() or blk_mq_end_request() runs bio->bi_end_io() callbacks 4. If this triggers fput() on file descriptor of ublk block device, the work may be deferred to current task's task work (see fput() implementation) 5. This eventually calls blkdev_release() from the same context 6. blkdev_release() tries to grab disk->open_mutex again 7. Deadlock: same task waiting for a mutex it already holds The fix is to run blk_update_request() and blk_mq_end_request() with bottom halves disabled. This forces blkdev_release() to run in kernel work-queue context instead of current task work context, and allows ublk server to make forward progress, and avoids the deadlock. Fixes: 71f28f3136af ("ublk_drv: add io_uring based userspace block driver") Link: https://github.com/ublk-org/ublksrv/issues/170 [1] Signed-off-by: Ming Lei <ming.lei@redhat.com> Reviewed-by: Caleb Sander Mateos <csander@purestorage.com> [axboe: rewrite comment in ublk] Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-12-17ftrace: Fix address for jmp mode in t_show()Menglong Dong
The address from ftrace_find_rec_direct() is printed directly in t_show(). This can mislead symbol offsets if it has the "jmp" bit in the last bit. Fix this by printing the address that returned by ftrace_jmp_get(). Link: https://patch.msgid.link/20251217030053.80343-1-dongml2@chinatelecom.cn Fixes: 25e4e3565d45 ("ftrace: Introduce FTRACE_OPS_FL_JMP") Signed-off-by: Menglong Dong <dongml2@chinatelecom.cn> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2025-12-17tracing: Fix UBSAN warning in __remove_instance()Darrick J. Wong
xfs/558 triggers the following UBSAN warning: ------------[ cut here ]------------ UBSAN: shift-out-of-bounds in kernel/trace/trace.c:10510:10 shift exponent 32 is too large for 32-bit type 'int' CPU: 1 UID: 0 PID: 888674 Comm: rmdir Not tainted 6.19.0-rc1-xfsx #rc1 PREEMPT(lazy) dbf607ef4c142c563f76d706e71af9731d7b9c90 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-4.module+el8.8.0+21164+ed375313 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x4a/0x70 ubsan_epilogue+0x5/0x2b __ubsan_handle_shift_out_of_bounds.cold+0x5e/0x113 __remove_instance.part.0.constprop.0.cold+0x18/0x26f instance_rmdir+0xf3/0x110 tracefs_syscall_rmdir+0x4d/0x90 vfs_rmdir+0x139/0x230 do_rmdir+0x143/0x230 __x64_sys_rmdir+0x1d/0x20 do_syscall_64+0x44/0x230 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f7ae8e51f17 Code: f0 ff ff 73 01 c3 48 8b 0d de 2e 0e 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 b8 54 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 01 c3 48 8b 15 b1 2e 0e 00 f7 d8 64 89 02 b8 RSP: 002b:00007ffd90743f08 EFLAGS: 00000246 ORIG_RAX: 0000000000000054 RAX: ffffffffffffffda RBX: 00007ffd907440f8 RCX: 00007f7ae8e51f17 RDX: 00007f7ae8f3c5c0 RSI: 00007ffd90744a21 RDI: 00007ffd90744a21 RBP: 0000000000000002 R08: 0000000000000000 R09: 0000000000000000 R10: 00007f7ae8f35ac0 R11: 0000000000000246 R12: 00007ffd90744a21 R13: 0000000000000001 R14: 00007f7ae8f8b000 R15: 000055e5283e6a98 </TASK> ---[ end trace ]--- whilst tearing down an ftrace instance. TRACE_FLAGS_MAX_SIZE is now 64bit, so the mask comparison expression must be typecast to a u64 value to avoid an overflow. AFAICT, ZEROED_TRACE_FLAGS is already cast to ULL so this is ok. Link: https://patch.msgid.link/20251216174950.GA7705@frogsfrogsfrogs Fixes: bbec8e28cac592 ("tracing: Allow tracer to add more than 32 options") Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2025-12-17drm/xe/pf: Add handling for MLRC adverse event thresholdDaniele Ceraolo Spurio
Since it is illegal to register a MLRC context when scheduler groups are enabled, the GuC consider the VF doing so as an adverse event. Like for other adverse event, there is a threshold for how many times the event can happen before the GuC throws an error, which we need to add support for. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Acked-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20251216214902.1429-5-michal.wajdeczko@intel.com
2025-12-17drm/xe/pf: Prepare for new threshold KLVsMichal Wajdeczko
We want to extend our macro-based KLV list definitions with new information about the version from which given KLV is supported. Prepare our code generators to emit dedicated version check if a KLV was defined with the version information. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Acked-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20251216214902.1429-4-michal.wajdeczko@intel.com
2025-12-17drm/xe/guc: Introduce GUC_FIRMWARE_VER_AT_LEAST helperMichal Wajdeczko
There are already few places in the code where we need to check GuC firmware version. Wrap existing raw conditions into a named helper macro to make it clear and avoid explicit call of the MAKE_GUC_VER. Suggested-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Acked-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20251216214902.1429-3-michal.wajdeczko@intel.com
generated by cgit v1.2.3 (git 2.25.1) at 2026-03-18 16:32:09 +0000