summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-12-18Documentation: gpio: add TCAL6408 and TCAL6416Jan Remmet
Checked datasheets, the offsets are identical to pcal6408 and pcal6416. Signed-off-by: Jan Remmet <j.remmet@phytec.de> Link: https://lore.kernel.org/r/20251216-wip-jremmet-tcal6416rtw-v2-1-6516d98a9836@phytec.de Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2025-12-18dma-buf: add some tracepoints to debug.gaoxiang17
Since we can only inspect dmabuf by iterating over process FDs or the dmabuf_list, we need to add our own tracepoints to track its status in real time in production. For example: binder:3016_1-3102 [006] ...1. 255.126521: dma_buf_export: exp_name=qcom,system size=12685312 ino=2738 binder:3016_1-3102 [006] ...1. 255.126528: dma_buf_fd: exp_name=qcom,system size=12685312 ino=2738 fd=8 binder:3016_1-3102 [006] ...1. 255.126642: dma_buf_mmap_internal: exp_name=qcom,system size=28672 ino=2739 kworker/6:1-86 [006] ...1. 255.127194: dma_buf_put: exp_name=qcom,system size=12685312 ino=2738 RenderThread-9293 [006] ...1. 316.618179: dma_buf_get: exp_name=qcom,system size=12771328 ino=2762 fd=176 RenderThread-9293 [006] ...1. 316.618195: dma_buf_dynamic_attach: exp_name=qcom,system size=12771328 ino=2762 attachment:ffffff880a18dd00 is_dynamic=0 dev_name=kgsl-3d0 RenderThread-9293 [006] ...1. 318.878220: dma_buf_detach: exp_name=qcom,system size=12771328 ino=2762 attachment:ffffff880a18dd00 is_dynamic=0 dev_name=kgsl-3d0 Signed-off-by: Xiang Gao <gaoxiang17@xiaomi.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://lore.kernel.org/r/20251218062853.819744-1-gxxa03070307@gmail.com Signed-off-by: Christian König <christian.koenig@amd.com>
2025-12-18media: vb2: drop wait_prepare/finish callbacksHans Verkuil
Drop the wait_prepare/finish callbacks. Instead require that the vb2_queue lock field is always set and use that lock when waiting for buffers to arrive. Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2025-12-18media: vb2: remove vb2_ops_wait_prepare/finish helpersHans Verkuil
Since vb2 now relies on the presence of the vb2_queue lock field and there are no more drivers that use these helpers, it is safe to drop them. Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2025-12-18media: dvb-core: dvb_vb2: drop wait_prepare/finish callbacksHans Verkuil
Since commit 88785982a19d ("media: vb2: use lock if wait_prepare/finish are NULL") it is no longer needed to set the wait_prepare/finish vb2_ops callbacks as long as the lock field in vb2_queue is set. Set the queue lock to &ctx->mutex, which makes it possible to drop the wait_prepare/finish callbacks. This simplifies the code and this is a step towards the goal of deleting these callbacks. Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2025-12-18media: dvb-core/dmxdev: drop locks around mmap()Hans Verkuil
vb2 no longer requires locking around mmap since commit f035eb4e976e ("[media] videobuf2: fix lockdep warning"). Since the streaming I/O mode for DVB support is by default off, and the dvb utilities were never updated with streaming support, and we never had regression tests for this streaming mode, this was never noticed before. Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2025-12-18media: dvb-core: dmxdevfilter must always flush bufsHans Verkuil
Currently the buffers are being filled until full, which works fine for the transport stream, but not when reading sections, those have to be returned to userspace immediately, otherwise dvbv5-scan will just wait forever. Add a 'flush' argument to dvb_vb2_fill_buffer to indicate whether the buffer must be flushed or wait until it is full. Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2025-12-18drm/gem: Fix kerneldoc warningsLoïc Molinari
Fix incorrect parameters in drm_gem_shmem_init() and missing " *" on empty lines in drm_gem_get_huge_mnt(). Signed-off-by: Loïc Molinari <loic.molinari@collabora.com> Fixes: 6e0b1b82017b ("drm/gem: Add huge tmpfs mountpoint helpers") Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Closes: https://lore.kernel.org/dri-devel/20251216115605.4babbce0@canb.auug.org.au/ Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Tested-by: Randy Dunlap <rdunlap@infradead.org> Link: https://patch.msgid.link/20251217172404.31216-1-loic.molinari@collabora.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
2025-12-18drm/panthor: unlock on error in panthor_ioctl_bo_create()Dan Carpenter
Call drm_dev_exit() before returning -EINVAL. Fixes: cd2c9c3015e6 ("drm/panthor: Add flag to map GEM object Write-Back Cacheable") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patch.msgid.link/aUOxxvXXtHHfFCcg@stanley.mountain Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
2025-12-18drm/i915: Add intel_gvt_driver_remove() onto error cleanup pathJuha-Pekka Heikkila
Add intel_gvt_driver_remove() onto error cleanup path. Signed-off-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Reviewed-by: Zhenyu Wang <zhenyuw.linux@gmail.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Link: https://patch.msgid.link/20251216080754.221974-3-juhapekka.heikkila@gmail.com
2025-12-18drm/i915: switch to use kernel standard error injectionJuha-Pekka Heikkila
Switch error injection testing from i915_inject_probe_failure to ALLOW_ERROR_INJECTION. Here taken out calls to i915_inject_probe_failure and changed to use ALLOW_ERROR_INJECTION for the same functions. Below functions are dropped from testing since I couldn't hit those at module bind time, testing these would just fail the tests. To include these in test would need to find way to cause resetting in i915 which would trigger these: intel_gvt_init intel_wopcm_init intel_uc_fw_upload intel_gt_init with expected -EIO (-EINVAL is tested) lrc_init_wa_ctx intel_huc_auth guc_check_version_range intel_uc_fw_fetch uc_fw_xfer __intel_uc_reset_hw guc_enable_communication uc_init_wopcm ..and all stages of __force_fw_fetch_failures Signed-off-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Link: https://patch.msgid.link/20251216080754.221974-2-juhapekka.heikkila@gmail.com
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>
generated by cgit v1.2.3 (git 2.25.1) at 2026-05-21 12:44:47 +0000