summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2025-08-18pinctrl: single: fix bias pull up/down handling in pin_config_setChi Zhang
In the pin_config_set function, when handling PIN_CONFIG_BIAS_PULL_DOWN or PIN_CONFIG_BIAS_PULL_UP, the function calls pcs_pinconf_clear_bias() which writes the register. However, the subsequent operations continue using the stale 'data' value from before the register write, effectively causing the bias clear operation to be overwritten and not take effect. Fix this by reading the 'data' value from the register after calling pcs_pinconf_clear_bias(). This bug seems to have existed when this code was first merged in commit 9dddb4df90d1 ("pinctrl: single: support generic pinconf"). Signed-off-by: Chi Zhang <chizhang@asrmicro.com> Link: https://lore.kernel.org/20250807062038.13610-1-chizhang@asrmicro.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2025-08-18pinctrl: spacemit: remove extra line in debug outputHendrik Hamerlinck
The debug output for spacemit_pinconf_dbg_show() prints an extra newline at the end. This is redundant as pinconf_pins_show() in pinconf.c already adds a newline in its for loop. Remove the newline to avoid the extra line in the output. Example current output: $ cat /sys/kernel/debug/pinctrl/d401e000.pinctrl/pinconf-pins Pin config settings per pin Format: pin (name): configs pin 0 (GPIO_00): , bias pull disabled, io type (Fixed/1V8), drive strength (32 mA), register (0x1041) pin 1 (GPIO_01): slew rate (0x0), bias pull disabled, io type (Fixed/1V8), drive strength (32 mA), register (0x1041) pin 2 (GPIO_02): slew rate (0x0), bias pull disabled, io type (Fixed/1V8), drive strength (32 mA), register (0x1041) ... Signed-off-by: Hendrik Hamerlinck <hendrik.hamerlinck@hammernet.be> Reviewed-by: Yixun Lan <dlan@gentoo.org> Link: https://lore.kernel.org/20250805150701.129113-1-hendrik.hamerlinck@hammernet.be Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2025-08-18drm/msm: skip re-emitting IBs for unusable VMsAntonino Maniscalco
When a VM is marked as an usuable we disallow new submissions from it, however submissions that where already scheduled on the ring would still be re-sent. Since this can lead to further hangs, avoid emitting the actual IBs. Fixes: 6a4d287a1ae6 ("drm/msm: Mark VM as unusable on GPU hangs") Signed-off-by: Antonino Maniscalco <antomani103@gmail.com> Reviewed-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/668314/ Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2025-08-18drm/msm: Don't use %pK through printkThomas Weißschuh
In the past %pK was preferable to %p as it would not leak raw pointer values into the kernel log. Since commit ad67b74d2469 ("printk: hash addresses printed with %p") the regular %p has been improved to avoid this issue. Furthermore, restricted pointers ("%pK") were never meant to be used through printk(). They can still unintentionally leak raw pointers or acquire sleeping locks in atomic contexts. Switch to the regular pointer formatting which is safer and easier to reason about. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/667895/ Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2025-08-18staging: axis-fifo: fix maximum TX packet length checkOvidiu Panait
Since commit 2ca34b508774 ("staging: axis-fifo: Correct handling of tx_fifo_depth for size validation"), write() operations with packets larger than 'tx_fifo_depth - 4' words are no longer rejected with -EINVAL. Fortunately, the packets are not actually getting transmitted to hardware, otherwise they would be raising a 'Transmit Packet Overrun Error' interrupt, which requires a reset of the TX circuit to recover from. Instead, the request times out inside wait_event_interruptible_timeout() and always returns -EAGAIN, since the wake up condition can never be true for these packets. But still, they unnecessarily block other tasks from writing to the FIFO and the EAGAIN return code signals userspace to retry the write() call, even though it will always fail and time out. According to the AXI4-Stream FIFO reference manual (PG080), the maximum valid packet length is 'tx_fifo_depth - 4' words, so attempting to send larger packets is invalid and should not be happening in the first place: > The maximum packet that can be transmitted is limited by the size of > the FIFO, which is (C_TX_FIFO_DEPTH–4)*(data interface width/8) bytes. Therefore, bring back the old behavior and outright reject packets larger than 'tx_fifo_depth - 4' with -EINVAL. Add a comment to explain why the check is necessary. The dev_err() message was removed to avoid cluttering the dmesg log if an invalid packet is received from userspace. Fixes: 2ca34b508774 ("staging: axis-fifo: Correct handling of tx_fifo_depth for size validation") Cc: stable@vger.kernel.org Signed-off-by: Ovidiu Panait <ovidiu.panait.oss@gmail.com> Link: https://lore.kernel.org/r/20250817171350.872105-1-ovidiu.panait.oss@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-08-18iommufd: viommu: free memory allocated by kvcalloc() using kvfree()Akhilesh Patil
Use kvfree() instead of kfree() to free pages allocated by kvcalloc() in iommufs_hw_queue_alloc_phys() to fix potential memory corruption. Ensure the memory is properly freed, as kvcalloc may internally use vmalloc or kmalloc depending on available memory in the system. Fixes: 2238ddc2b056 ("iommufd/viommu: Add IOMMUFD_CMD_HW_QUEUE_ALLOC ioctl") Link: https://patch.msgid.link/r/aJifyVV2PL6WGEs6@bhairav-test.ee.iitb.ac.in Signed-off-by: Akhilesh Patil <akhilesh@ee.iitb.ac.in> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Nicolin Chen <nicolinc@nvidia.com> Reviewed-by: Pranjal Shrivastava <praan@google.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2025-08-18tee: optee: ffa: fix a typo of "optee_ffa_api_is_compatible"Sungbae Yoo
Fixes optee_ffa_api_is_compatbile() to optee_ffa_api_is_compatible() because compatbile is a typo of compatible. Fixes: 4615e5a34b95 ("optee: add FF-A support") Signed-off-by: Sungbae Yoo <sungbaey@nvidia.com> Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
2025-08-18objtool: Validate kCFI callsPeter Zijlstra
Validate that all indirect calls adhere to kCFI rules. Notably doing nocfi indirect call to a cfi function is broken. Apparently some Rust 'core' code violates this and explodes when ran with FineIBT. All the ANNOTATE_NOCFI_SYM sites are prime targets for attackers. - runtime EFI is especially henous because it also needs to disable IBT. Basically calling unknown code without CFI protection at runtime is a massice security issue. - Kexec image handover; if you can exploit this, you get to keep it :-) Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Josh Poimboeuf <jpoimboe@kernel.org> Acked-by: Sean Christopherson <seanjc@google.com> Link: https://lkml.kernel.org/r/20250714103441.496787279@infradead.org
2025-08-18spi: spl022: use min_t() to improve codeQianfeng Rong
Use min_t() to reduce the code in setup_dma_scatter() and improve its readability. Signed-off-by: Qianfeng Rong <rongqianfeng@vivo.com> Link: https://patch.msgid.link/20250815082118.586422-4-rongqianfeng@vivo.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-08-18spi: npcm-fiu: use min_t() to improve codeQianfeng Rong
Use min_t() to reduce the code in npcm_fiu_read() and improve its readability. Signed-off-by: Qianfeng Rong <rongqianfeng@vivo.com> Link: https://patch.msgid.link/20250815082118.586422-3-rongqianfeng@vivo.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-08-18spi: spi-fsl-lpspi: use min_t() to improve codeQianfeng Rong
Use min_t() to reduce the code in fsl_lpspi_setup_transfer() and improve its readability. Signed-off-by: Qianfeng Rong <rongqianfeng@vivo.com> Link: https://patch.msgid.link/20250815082118.586422-2-rongqianfeng@vivo.com Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2025-08-18spi: offload trigger: adi-util-sigma-delta: clean up importsDavid Lechner
Clean up imports using include-what-you-use principles. Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/20250815-spi-offload-trigger-followup-v1-2-8ec5413a8383@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-08-18regulator: bd718x7: Use kcalloc() instead of kzalloc()Qianfeng Rong
Replace calls of 'devm_kzalloc(dev, count * sizeof([type]), flags)' with 'devm_kcalloc(dev, count, sizeof([type]), flags)' in setup_feedback_loop() for safer memory allocation with built-in overflow protection. Signed-off-by: Qianfeng Rong <rongqianfeng@vivo.com> Reviewed-by: Matti Vaittinen <mazziesaccount@gmail.com> Link: https://patch.msgid.link/20250817142327.174531-1-rongqianfeng@vivo.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-08-18regulator: pca9450: Use devm_register_sys_off_handlerPeng Fan
With module test, there is error dump: ------------[ cut here ]------------ notifier callback pca9450_i2c_restart_handler already registered WARNING: kernel/notifier.c:23 at notifier_chain_register+0x5c/0x88, CPU#0: kworker/u16:3/50 Call trace: notifier_chain_register+0x5c/0x88 (P) atomic_notifier_chain_register+0x30/0x58 register_restart_handler+0x1c/0x28 pca9450_i2c_probe+0x418/0x538 i2c_device_probe+0x220/0x3d0 really_probe+0x114/0x410 __driver_probe_device+0xa0/0x150 driver_probe_device+0x40/0x114 __device_attach_driver+0xd4/0x12c So use devm_register_sys_off_handler to let kernel handle the resource free to avoid kernel dump. Fixes: 6157e62b07d9 ("regulator: pca9450: Add restart handler") Signed-off-by: Peng Fan <peng.fan@nxp.com> Link: https://patch.msgid.link/20250815-pca9450-v1-1-7748e362dc97@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-08-18interconnect: qcom: add glymur interconnect provider driverRaviteja Laggyshetty
Add driver for the Qualcomm interconnect buses found in glymur based platforms. The topology consists of several NoCs that are controlled by a remote processor that collects the aggregated bandwidth for each master-slave pairs. Co-developed-by: Odelu Kukatla <odelu.kukatla@oss.qualcomm.com> Signed-off-by: Odelu Kukatla <odelu.kukatla@oss.qualcomm.com> Signed-off-by: Raviteja Laggyshetty <raviteja.laggyshetty@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250814-glymur-icc-v2-3-596cca6b6015@oss.qualcomm.com Signed-off-by: Georgi Djakov <djakov@kernel.org>
2025-08-18interconnect: qcom: icc-rpmh: increase MAX_PORTS to support four QoS portsRaviteja Laggyshetty
Update the MAX_PORTS value to 4 to program four QoS ports available on the Glymur SoC's interconnect master node. Co-developed-by: Odelu Kukatla <odelu.kukatla@oss.qualcomm.com> Signed-off-by: Odelu Kukatla <odelu.kukatla@oss.qualcomm.com> Signed-off-by: Raviteja Laggyshetty <raviteja.laggyshetty@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250814-glymur-icc-v2-2-596cca6b6015@oss.qualcomm.com Signed-off-by: Georgi Djakov <djakov@kernel.org>
2025-08-18memstick: Fix deadlock by moving removing flag earlierJiayi Li
The existing memstick core patch: commit 62c59a8786e6 ("memstick: Skip allocating card when removing host") sets host->removing in memstick_remove_host(),but still exists a critical time window where memstick_check can run after host->eject is set but before removing is set. In the rtsx_usb_ms driver, the problematic sequence is: rtsx_usb_ms_drv_remove: memstick_check: host->eject = true cancel_work_sync(handle_req) if(!host->removing) ... memstick_alloc_card() memstick_set_rw_addr() memstick_new_req() rtsx_usb_ms_request() if(!host->eject) skip schedule_work wait_for_completion() memstick_remove_host: [blocks indefinitely] host->removing = true flush_workqueue() [block] 1. rtsx_usb_ms_drv_remove sets host->eject = true 2. cancel_work_sync(&host->handle_req) runs 3. memstick_check work may be executed here <-- danger window 4. memstick_remove_host sets removing = 1 During this window (step 3), memstick_check calls memstick_alloc_card, which may indefinitely waiting for mrq_complete completion that will never occur because rtsx_usb_ms_request sees eject=true and skips scheduling work, memstick_set_rw_addr waits forever for completion. This causes a deadlock when memstick_remove_host tries to flush_workqueue, waiting for memstick_check to complete, while memstick_check is blocked waiting for mrq_complete completion. Fix this by setting removing=true at the start of rtsx_usb_ms_drv_remove, before any work cancellation. This ensures memstick_check will see the removing flag immediately and exit early, avoiding the deadlock. Fixes: 62c59a8786e6 ("memstick: Skip allocating card when removing host") Signed-off-by: Jiayi Li <lijiayi@kylinos.cn> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250804013604.1311218-1-lijiayi@kylinos.cn Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2025-08-18binder: remove MODULE_LICENSE()Carlos Llamas
The MODULE_LICENSE() macro is intended for drivers that can be built as loadable modules. The binder driver is always built-in, using this macro here is unnecessary and potentially confusing. Remove it. Cc: Salvatore Bonaccorso <carnil@debian.org> Signed-off-by: Carlos Llamas <cmllamas@google.com> Link: https://lore.kernel.org/r/20250817135034.3692902-1-cmllamas@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-08-18mmc: sdhci-of-arasan: Ensure CD logic stabilization before power-upSai Krishna Potthuri
During SD suspend/resume without a full card rescan (when using non-removable SD cards for rootfs), the SD card initialization may fail after resume. This occurs because, after a host controller reset, the card detect logic may take time to stabilize due to debounce logic. Without waiting for stabilization, the host may attempt powering up the card prematurely, leading to command timeouts during resume flow. Add sdhci_arasan_set_power_and_bus_voltage() to wait for the card detect stable bit before power up the card. Since the stabilization time is not fixed, a maximum timeout of one second is used to ensure sufficient wait time for the card detect signal to stabilize. Signed-off-by: Sai Krishna Potthuri <sai.krishna.potthuri@amd.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250730060543.1735971-1-sai.krishna.potthuri@amd.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2025-08-18mmc: sdhci-pci-gli: GL9763e: Mask the replay timer timeout of AERVictor Shih
Due to a flaw in the hardware design, the GL9763e replay timer frequently times out when ASPM is enabled. As a result, the warning messages will often appear in the system log when the system accesses the GL9763e PCI config. Therefore, the replay timer timeout must be masked. Signed-off-by: Victor Shih <victor.shih@genesyslogic.com.tw> Fixes: 1ae1d2d6e555 ("mmc: sdhci-pci-gli: Add Genesys Logic GL9763E support") Cc: stable@vger.kernel.org Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20250731065752.450231-4-victorshihgli@gmail.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2025-08-18mmc: sdhci-pci-gli: GL9763e: Rename the gli_set_gl9763e() for consistencyVictor Shih
In preparation to fix replay timer timeout, rename the gli_set_gl9763e() to gl9763e_hw_setting() for consistency. Signed-off-by: Victor Shih <victor.shih@genesyslogic.com.tw> Fixes: 1ae1d2d6e555 ("mmc: sdhci-pci-gli: Add Genesys Logic GL9763E support") Cc: stable@vger.kernel.org Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20250731065752.450231-3-victorshihgli@gmail.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2025-08-18mmc: sdhci-pci-gli: Add a new function to simplify the codeVictor Shih
In preparation to fix replay timer timeout, add sdhci_gli_mask_replay_timer_timeout() function to simplify some of the code, allowing it to be re-used. Signed-off-by: Victor Shih <victor.shih@genesyslogic.com.tw> Fixes: 1ae1d2d6e555 ("mmc: sdhci-pci-gli: Add Genesys Logic GL9763E support") Cc: stable@vger.kernel.org Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20250731065752.450231-2-victorshihgli@gmail.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2025-08-18mmc: davinci: Remove space before newlineColin Ian King
There is a extraneous space before a newline in a dev_err message. Remove the space. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Link: https://lore.kernel.org/r/20250731094116.2163061-1-colin.i.king@gmail.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2025-08-18mmc: Kconfig: Fix spelling mistake "referrered" -> "referred"Colin Ian King
There are two spelling mistakes in the config. Fix them. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Link: https://lore.kernel.org/r/20250724112817.142784-1-colin.i.king@gmail.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2025-08-18mmc: sdhci: Disable SD card clock before changing parametersErick Shepherd
Per the SD Host Controller Simplified Specification v4.20 §3.2.3, change the SD card clock parameters only after first disabling the external card clock. Doing this fixes a spurious clock pulse on Baytrail and Apollo Lake SD controllers which otherwise breaks voltage switching with a specific Swissbit SD card. This change is limited to Intel host controllers to avoid an issue reported on ARM64 devices. Signed-off-by: Kyle Roeschley <kyle.roeschley@ni.com> Signed-off-by: Brad Mouring <brad.mouring@ni.com> Signed-off-by: Erick Shepherd <erick.shepherd@ni.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20250724185354.815888-1-erick.shepherd@ni.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2025-08-18pinctrl: meson: Fix typo in device table macroAlexey Gladkov
The typo when using the MODULE_DEVICE_TABLE macro was not noticeable because the macro was defined only if the module was built as a separate module. Cc: Xianwei Zhao <xianwei.zhao@amlogic.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Neil Armstrong <neil.armstrong@linaro.org> Cc: Kevin Hilman <khilman@baylibre.com> Cc: linux-amlogic@lists.infradead.org Cc: linux-gpio@vger.kernel.org Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202507220009.8HKbNP16-lkp@intel.com/ Signed-off-by: Alexey Gladkov <legion@kernel.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/e548b7761302defec15aa2098172eabb1ce1ad4a.1755170493.git.legion@kernel.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2025-08-18leds: flash: leds-qcom-flash: Add a separate register map for PMI8998Fenglin Wu
The 3-channel flash module in PMI8998 has several registers different than the others, such as: torch_clamp. Add different register fields for it. Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250729-fix-torch-clamp-issue-v2-2-9b83816437a3@oss.qualcomm.com Signed-off-by: Lee Jones <lee@kernel.org>
2025-08-18leds: flash: leds-qcom-flash: Update torch current clamp settingFenglin Wu
There is a register to clamp the flash current per LED channel when safety timer is disabled. It needs to be updated according to the maximum torch LED current setting to ensure the torch current won't be clamped unexpectedly. Fixes: 96a2e242a5dc ("leds: flash: Add driver to support flash LED module in QCOM PMICs") Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250729-fix-torch-clamp-issue-v2-1-9b83816437a3@oss.qualcomm.com Signed-off-by: Lee Jones <lee@kernel.org>
2025-08-18leds: max77705: Function return instead of variable assignmentLen Bao
Coverity noticed that assigning value -EINVAL to 'ret' in the if statement is useless because 'ret' is overwritten a few lines later. However, after inspect the code, this warning reveals that we need to return -EINVAL instead of the variable assignment. So, fix it. Coverity-id: 1646104 Fixes: aebb5fc9a0d8 ("leds: max77705: Add LEDs support") Signed-off-by: Len Bao <len.bao@gmx.us> Link: https://lore.kernel.org/r/20250727075649.34496-1-len.bao@gmx.us Signed-off-by: Lee Jones <lee@kernel.org>
2025-08-18leds: Kconfig: Fix spelling mistake "limitiation" -> "limitation"Colin Ian King
There is a spelling mistake in the LEDS_BD2606MVV config. Fix it. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Link: https://lore.kernel.org/r/20250724112030.142121-1-colin.i.king@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
2025-08-18leds: leds-is31fl32xx: Add support for is31fl3236aPawel Zalewski
Also add an additional and optional control register for setting the output PWM frequency to 22kHz. The default is 3kHz and this option puts the operational frequency outside of the audible range. Signed-off-by: Pawel Zalewski <pzalewski@thegoodpenguin.co.uk> Link: https://lore.kernel.org/r/20250723-leds-is31fl3236a-v6-3-210328058625@thegoodpenguin.co.uk Signed-off-by: Lee Jones <lee@kernel.org>
2025-08-18clk: samsung: fsd: Add clk id for PCLK and PLL in CAM_CSI blockInbaraj E
Add clock id for PCLK and PLL. These clock id will be used for operation of CSI driver. PCLK is AXI2APB clock used for register access. PLL clock is main clock source for CAM_CSI block. Signed-off-by: Inbaraj E <inbaraj.e@samsung.com> Link: https://lore.kernel.org/r/20250814140943.22531-3-inbaraj.e@samsung.com Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2025-08-18media: Remove redundant pm_runtime_mark_last_busy() callsSakari Ailus
pm_runtime_put_autosuspend(), pm_runtime_put_sync_autosuspend(), pm_runtime_autosuspend() and pm_request_autosuspend() now include a call to pm_runtime_mark_last_busy(). Remove the now-reduntant explicit call to pm_runtime_mark_last_busy(). Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Thierry Reding <treding@nvidia.com> (tegra-vde/h264.c) Acked-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> (alvium-csi2.c) Reviewed-by: Dikshita Agarwal <quic_dikshita@quicinc.com> (iris_hfi_queue.c) Reviewed-by: Sean Young <sean@mess.org> Acked-by: Dave Stevenson <dave.stevenson@raspberrypi.com> (imx219.c) Acked-by: Benjamin Mugnier <benjamin.mugnier@foss.st.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2025-08-18platform/x86: int3472: add hpd pin supportDongcheng Yan
Typically HDMI to MIPI CSI-2 bridges have a pin to signal image data is being received. On the host side this is wired to a GPIO for polling or interrupts. This includes the Lontium HDMI to MIPI CSI-2 bridges lt6911uxe and lt6911uxc. The GPIO "hpd" is used already by other HDMI to CSI-2 bridges, use it here as well. Signed-off-by: Dongcheng Yan <dongcheng.yan@intel.com> Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Acked-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Fixes: 20244cbafbd6 ("media: i2c: change lt6911uxe irq_gpio name to "hpd"") Cc: stable@vger.kernel.org Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2025-08-18media: rkvdec: Remove redundant pm_runtime_mark_last_busy() callsSakari Ailus
pm_runtime_put_autosuspend(), pm_runtime_put_sync_autosuspend(), pm_runtime_autosuspend() and pm_request_autosuspend() now include a call to pm_runtime_mark_last_busy(). Remove the now-reduntant explicit call to pm_runtime_mark_last_busy(). Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2025-08-18media: rkvdec: Fix an error handling path in rkvdec_probe()Christophe JAILLET
If an error occurs after a successful iommu_paging_domain_alloc() call, it should be undone by a corresponding iommu_domain_free() call, as already done in the remove function. In order to fix the issue, move the corresponding call at the end of the function, because it is safe to allocate 'empty_domain' later. Fixes: ff8c5622f9f7 ("media: rkvdec: Restore iommu addresses on errors") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2025-08-18media: rkvdec: Fix a NULL vs IS_ERR() bug in probe()Dan Carpenter
The iommu_paging_domain_alloc() function doesn't return NULL on error it returns error pointers. Update the check and then set ->empty_domain to NULL because the rest of the driver assumes it can be NULL. Fixes: ff8c5622f9f7 ("media: rkvdec: Restore iommu addresses on errors") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Tested-by: Detlev Casanova <detlev.casanova@collabora.com> Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2025-08-18clk: renesas: mstp: Add genpd OF provider at postcore_initcall()Geert Uytterhoeven
Genpd OF providers must now be registered after genpd bus registration. However, cpg_mstp_add_clk_domain() is only called from CLK_OF_DECLARE(), which is too early. Hence on R-Car M1A, R-Car H1, and RZ/A1, the CPG/MSTP Clock Domain fails to register, and any devices residing in that clock domain fail to probe. Fix this by splitting initialization into two steps: - The first part keeps on registering the PM domain with genpd at CLK_OF_DECLARE(), - The second and new part moves the registration of the genpd OF provider to a postcore_initcall(). See also commit c5ae5a0c61120d0c ("pmdomain: renesas: rcar-sysc: Add genpd OF provider at postcore_initcall"). Fixes: 18a3a510ecfd0e50 ("pmdomain: core: Add the genpd->dev to the genpd provider bus") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://lore.kernel.org/81ef5f8d5d31374b7852b05453c52d2f735062a2.1755073087.git.geert+renesas@glider.be
2025-08-18drm/i915/icl+/tc: Convert AUX powered WARN to a debug messageImre Deak
The BIOS can leave the AUX power well enabled on an output, even if this isn't required (on platforms where the AUX power is only needed for an AUX access). This was observed at least on PTL. To avoid the WARN which would be triggered by this during the HW readout, convert the WARN to a debug message. Cc: stable@vger.kernel.org # v6.8+ Reported-by: Charlton Lin <charlton.lin@intel.com> Tested-by: Khaled Almahallawy <khaled.almahallawy@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/20250811080152.906216-6-imre.deak@intel.com (cherry picked from commit 6cb52cba474b2bec1a3018d3dbf75292059a29a1) Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
2025-08-18drm/i915/lnl+/tc: Use the cached max lane count valueImre Deak
Use the cached max lane count value on LNL+, to account for scenarios where this value is queried after the HW cleared the corresponding pin assignment value in the TCSS_DDI_STATUS register after the sink got disconnected. For consistency, follow-up changes will use the cached max lane count value on other platforms as well and will also cache the pin assignment value in a similar way. Cc: stable@vger.kernel.org # v6.8+ Reported-by: Charlton Lin <charlton.lin@intel.com> Tested-by: Khaled Almahallawy <khaled.almahallawy@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/20250811080152.906216-5-imre.deak@intel.com (cherry picked from commit afc4e84388079f4d5ba05271632b7a4d8d85165c) Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
2025-08-18drm/i915/lnl+/tc: Fix max lane count HW readoutImre Deak
On LNL+ for a disconnected sink the pin assignment value gets cleared by the HW/FW as soon as the sink gets disconnected, even if the PHY ownership got acquired already by the BIOS/driver (and hence the PHY itself is still connected and used by the display). During HW readout this can result in detecting the PHY's max lane count as 0 - matching the above cleared aka NONE pin assignment HW state. For a connected PHY the driver in general (outside of intel_tc.c) expects the max lane count value to be valid for the video mode enabled on the corresponding output (1, 2 or 4). Ensure this by setting the max lane count to 4 in this case. Note, that it doesn't matter if this lane count happened to be more than the max lane count with which the PHY got connected and enabled, since the only thing the driver can do with such an output - where the DP-alt sink is disconnected - is to disable the output. v2: Rebased on change reading out the pin configuration only if the PHY is connected. Cc: stable@vger.kernel.org # v6.8+ Reported-by: Charlton Lin <charlton.lin@intel.com> Tested-by: Khaled Almahallawy <khaled.almahallawy@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/20250811080152.906216-4-imre.deak@intel.com (cherry picked from commit 33cf70bc0fe760224f892bc1854a33665f27d482) Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
2025-08-18drm/i915/icl+/tc: Cache the max lane count valueImre Deak
The PHY's pin assignment value in the TCSS_DDI_STATUS register - as set by the HW/FW based on the connected DP-alt sink's TypeC/PD pin assignment negotiation - gets cleared by the HW/FW on LNL+ as soon as the sink gets disconnected, even if the PHY ownership got acquired already by the driver (and hence the PHY itself is still connected and used by the display). This is similar to how the PHY Ready flag gets cleared on LNL+ in the same register. To be able to query the max lane count value on LNL+ - which is based on the above pin assignment - at all times even after the sink gets disconnected, the max lane count must be determined and cached during the PHY's HW readout and connect sequences. Do that here, leaving the actual use of the cached value to a follow-up change. v2: Don't read out the pin configuration if the PHY is disconnected. Cc: stable@vger.kernel.org # v6.8+ Reported-by: Charlton Lin <charlton.lin@intel.com> Tested-by: Khaled Almahallawy <khaled.almahallawy@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/20250811080152.906216-3-imre.deak@intel.com (cherry picked from commit 3e32438fc406761f81b1928d210b3d2a5e7501a0) Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
2025-08-18drm/i915/lnl+/tc: Fix handling of an enabled/disconnected dp-alt sinkImre Deak
The TypeC PHY HW readout during driver loading and system resume determines which TypeC mode the PHY is in (legacy/DP-alt/TBT-alt) and whether the PHY is connected, based on the PHY's Owned and Ready flags. For the PHY to be in DP-alt or legacy mode and for the PHY to be in the connected state in these modes, both the Owned (set by the BIOS/driver) and the Ready (set by the HW) flags should be set. On ICL-MTL the HW kept the PHY's Ready flag set after the driver connected the PHY by acquiring the PHY ownership (by setting the Owned flag), until the driver disconnected the PHY by releasing the PHY ownership (by clearing the Owned flag). On LNL+ this has changed, in that the HW clears the Ready flag as soon as the sink gets disconnected, even if the PHY ownership was acquired already and hence the PHY is being used by the display. When inheriting the HW state from BIOS for a PHY connected in DP-alt mode on which the sink got disconnected - i.e. in a case where the sink was connected while BIOS/GOP was running and so the sink got enabled connecting the PHY, but the user disconnected the sink by the time the driver loaded - the PHY Owned but not Ready state must be accounted for on LNL+ according to the above. Do that by assuming on LNL+ that the PHY is connected in DP-alt mode whenever the PHY Owned flag is set, regardless of the PHY Ready flag. This fixes a problem on LNL+, where the PHY TypeC mode / connected state was detected incorrectly for a DP-alt sink, which got connected and then disconnected by the user in the above way. v2: Rename tc_phy_in_legacy_or_dp_alt_mode() to tc_phy_owned_by_display(). (Luca, Jani) Cc: Jani Nikula <jani.nikula@intel.com> Cc: stable@vger.kernel.org # v6.8+ Reported-by: Charlton Lin <charlton.lin@intel.com> Tested-by: Khaled Almahallawy <khaled.almahallawy@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Luca Coelho <luciano.coelho@intel.com> [Imre: Add one-liner function documentation for tc_phy_owned_by_display()] Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/20250811080152.906216-2-imre.deak@intel.com (cherry picked from commit 89f4b196ee4b056e0e8c179b247b29d4a71a4e7e) Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
2025-08-17drm/xe/pm: Disable RPM for SR-IOV VFsSatyanarayana K V P
VFs without native PCIe Power Management (PM) capabilities inherit their PF's power state as per PCIe specifications(§5.10.1 PCIe Base Spec 7.0). Enabling Runtime Power Management (RPM) for these VFs trigger unnecessary driver suspend/resume operations that ultimately perform no PCI-level power transition. Since VFs without PM capabilities cannot independently enter low-power states, the existing RPM workflow becomes redundant: 1. Driver executes full suspend/resume sequence 2. PCI PM transition step becomes no-op 3. VF power state remains tied to PF's status Disabling RPM for VFs eliminates this redundant processing while maintaining proper power management through PF dependency. This optimization ensures VFs follow their PF's power state without superfluous runtime handling. Signed-off-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Cc: Anshuman Gupta <anshuman.gupta@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Maarten Lankhorst <dev@lankhorst.se> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/20250812163613.9954-1-satyanarayana.k.v.p@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-08-17drm/xe/i2c: Introduce xe_i2c_present()Raag Jadav
In preparation of wider usecases which require checking for I2C controller presence, introduce xe_i2c_present() helper. v2: Doc fix (Riana) Suggested-by: Riana Tauro <riana.tauro@intel.com> Signed-off-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Riana Tauro <riana.tauro@intel.com> Link: https://lore.kernel.org/r/20250814091845.1356135-1-raag.jadav@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-08-17drm/hisilicon/hibmc: fix dp and vga cannot show togetherBaihan Li
If VGA and DP connected together, there will be only one can get crtc. Add encoder possible_clones to support two connectors enable. Fixes: 3c7623fb5bb6 ("drm/hisilicon/hibmc: Enable this hot plug detect of irq feature") Signed-off-by: Baihan Li <libaihan@huawei.com> Signed-off-by: Yongbang Shi <shiyongbang@huawei.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250813094238.3722345-8-shiyongbang@huawei.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-08-17drm/hisilicon/hibmc: fix rare monitors cannot display problemBaihan Li
In some case, the dp link training success at 8.1Gbps, but the sink's maximum supported rate is less than 8.1G. So change the default 8.1Gbps link rate to the rate that reads from devices' capabilities. Fixes: 54063d86e036 ("drm/hisilicon/hibmc: add dp link moduel in hibmc drivers") Signed-off-by: Baihan Li <libaihan@huawei.com> Signed-off-by: Yongbang Shi <shiyongbang@huawei.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250813094238.3722345-6-shiyongbang@huawei.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-08-17drm/hisilicon/hibmc: fix the hibmc loaded failed bugBaihan Li
When hibmc loaded failed, the driver use hibmc_unload to free the resource, but the mutexes in mode.config are not init, which will access an NULL pointer. Just change goto statement to return, because hibnc_hw_init() doesn't need to free anything. Fixes: b3df5e65cc03 ("drm/hibmc: Drop drm_vblank_cleanup") Signed-off-by: Baihan Li <libaihan@huawei.com> Signed-off-by: Yongbang Shi <shiyongbang@huawei.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250813094238.3722345-5-shiyongbang@huawei.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-08-17drm/hisilicon/hibmc: fix irq_request()'s irq name variable is localBaihan Li
The local variable is passed in request_irq (), and there will be use after free problem, which will make request_irq failed. Using the global irq name instead of it to fix. Fixes: b11bc1ae4658 ("drm/hisilicon/hibmc: Add MSI irq getting and requesting for HPD") Signed-off-by: Baihan Li <libaihan@huawei.com> Signed-off-by: Yongbang Shi <shiyongbang@huawei.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250813094238.3722345-4-shiyongbang@huawei.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-08-17drm/hisilicon/hibmc: fix the i2c device resource leak when vdac init failedBaihan Li
Currently the driver missed to clean the i2c adapter when vdac init failed. It may cause resource leak. Fixes: a0d078d06e516 ("drm/hisilicon: Features to support reading resolutions from EDID") Signed-off-by: Baihan Li <libaihan@huawei.com> Signed-off-by: Yongbang Shi <shiyongbang@huawei.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250813094238.3722345-2-shiyongbang@huawei.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
generated by cgit v1.2.3 (git 2.25.1) at 2026-05-21 05:01:39 +0000