summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2026-07-15soc/tegra: pmc: Don't register sys-off handler for multi-socket devicesJon Hunter
The kernel does not permit a device to register multiple sys-off handlers for non-default priority levels. Hence, for multi-socket Tegra devices, registering the sys-off handler in the Tegra PMC driver (which uses the low priority level) more than once fails. The Tegra PMC sys-off handler is supported for all current generations of the Tegra SoC, however, it is only used as a low priority handler if everything else fails. For example, on Tegra264 the EFI reboot handler is called to restart the device. Therefore, for multi-socket devices, skip the registering of the sys-off handler to because this is not critical. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2026-07-15staging: rtl8723bs: Remove space after castJason Winter
Remove the unnecessary space after a cast in _rtw_init_recv_priv() to fix a checkpatch.pl coding style warning. Signed-off-by: Jason Winter <jjx@live.nl> Link: https://patch.msgid.link/BESP194MB2832DD527B23F20198ECDD9CB8FB2@BESP194MB2832.EURP194.PROD.OUTLOOK.COM Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-15iommu/amd: Fix nested domain leakTycho Andersen (AMD)
A couple of runs of different AI tools have generated something like the following bug report: In nested_domain_free(), when refcount_dec_and_test() returns false (other nested domains still reference the same gdom_info), the function returns without calling kfree(ndom), leaking the nested_domain structure. This problem wasn't introduced by this patch, but exists in the code from commit 757d2b1fdf5b that the patch modifies. Each nested_domain (ndom) is allocated individually in amd_iommu_alloc_domain_nested() via kzalloc_obj(*ndom). The .free callback is the sole point responsible for freeing this domain. When the refcount is > 0, only the xa_unlock_irqrestore is performed and the function returns, leaving ndom permanently allocated. This leak occurs every time a nested domain sharing a gDomID is destroyed while other domains still use that gDomID. There is a similar leak later in this function in the WARN_ON() test when the mapping is already NULL. Switch to a RAII-based cleanup for ndom, since it should always be freed in this function. Fixes: 757d2b1fdf5b ("iommu/amd: Introduce gDomID-to-hDomID Mapping and handle parent domain invalidation") Signed-off-by: Tycho Andersen (AMD) <tycho@kernel.org> Reviewed-by: Ankit Soni <Ankit.Soni@amd.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-07-15iommu/amd: Fix IRQ unsafe locking in gdom allocationTycho Andersen (AMD)
Lockdep complains: [ 259.410489] ===================================================== [ 259.417287] WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected [ 259.424667] 7.0.0-g51db1d8d2113 #54 Not tainted [ 259.429718] ----------------------------------------------------- [ 259.436516] qemu-system-x86/10143 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire: [ 259.444670] ff3b2b1c60305170 (&xa->xa_lock#25){+.+.}-{3:3}, at: __domain_flush_pages+0x17c/0x4b0 [ 259.454485] and this task is already holding: [ 259.460991] ff3b2b1c98504cc0 (&domain->lock){-.-.}-{3:3}, at: amd_iommu_iotlb_sync+0x25/0x60 [ 259.470408] which would create a new lock dependency: [ 259.476041] (&domain->lock){-.-.}-{3:3} -> (&xa->xa_lock#25){+.+.}-{3:3} [ 259.483615] but this new dependency connects a HARDIRQ-irq-safe lock: [ 259.492447] (&domain->lock){-.-.}-{3:3} [ 259.492449] ... which became HARDIRQ-irq-safe at: [ 259.503705] lock_acquire+0xb6/0x2e0 [ 259.507790] _raw_spin_lock_irqsave+0x3e/0x60 [ 259.512748] amd_iommu_flush_iotlb_all+0x20/0x50 [ 259.517996] iommu_dma_free_iova.isra.0+0x1b8/0x1e0 [ 259.523534] __iommu_dma_unmap+0xc2/0x140 [ 259.528100] iommu_dma_unmap_phys+0x55/0xc0 [ 259.532863] dma_unmap_phys+0x274/0x2e0 [ 259.537238] dma_unmap_page_attrs+0x17/0x30 [ 259.542000] nvme_unmap_data+0x13e/0x280 [ 259.546473] nvme_pci_complete_batch+0x45/0x70 [ 259.551524] nvme_irq+0x83/0x90 [ 259.555123] __handle_irq_event_percpu+0x92/0x360 [ 259.560466] handle_irq_event+0x39/0x80 [ 259.564841] handle_edge_irq+0xb2/0x1a0 [ 259.569214] __common_interrupt+0x4e/0x130 [ 259.573882] common_interrupt+0x88/0xa0 [ 259.578256] asm_common_interrupt+0x27/0x40 [ 259.583019] cpuidle_enter_state+0x119/0x5d0 [ 259.587877] cpuidle_enter+0x2e/0x50 [ 259.591962] do_idle+0x153/0x2c0 [ 259.595657] cpu_startup_entry+0x29/0x30 [ 259.600128] start_secondary+0x118/0x150 [ 259.604601] common_startup_64+0x13e/0x141 [ 259.609266] to a HARDIRQ-irq-unsafe lock: [ 259.615384] (&xa->xa_lock#25){+.+.}-{3:3} [ 259.615386] ... which became HARDIRQ-irq-unsafe at: [ 259.627039] ... [ 259.627039] lock_acquire+0xb6/0x2e0 [ 259.633071] _raw_spin_lock+0x2f/0x50 [ 259.637250] amd_iommu_alloc_domain_nested+0x140/0x3c0 [ 259.643078] iommufd_hwpt_alloc+0x272/0x800 [iommufd] [ 259.648813] iommufd_fops_ioctl+0x14e/0x200 [iommufd] [ 259.654547] __x64_sys_ioctl+0x9d/0xf0 ... Since amd_iommu_domain_flush_pages() necessarily holds domain->lock to do the flush, switch the allocation side in gdom_info_load_or_alloc_locked() to HARDIRQ-safe allocation. The IOMMU_DESTROY->free path has the same issue, so switch that path to HARDIRQ-safe locking as well. Fixes: 757d2b1fdf5b ("iommu/amd: Introduce gDomID-to-hDomID Mapping and handle parent domain invalidation") Signed-off-by: Tycho Andersen (AMD) <tycho@kernel.org> Reviewed-by: Ankit Soni <Ankit.Soni@amd.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-07-15drm/i915/display: expose blend mode on alpha-capable planesChaitanya Kumar Borah
Since commit 860e748bddcc ("drm: ensure blend mode supported if pixel format with alpha exposed"), drm_mode_config_validate() warns when a plane exposes an alpha pixel format but not the "pixel blend mode" property. The cursor (ARGB8888, all platforms) and the VLV/CHV primary and sprite planes trip this. Userspace has historically assumed premultiplied blending when the property is not attached, so it is safe to assume that planes that did not expose the property already blended with fixed pre-multiplied alpha in hardware. Therefore, expose a "pixel blend mode" property advertising only DRM_MODE_BLEND_PREMULTI to match that assumption and silence the warning. The cursor call is unconditional; the primary and sprite calls are gated to VLV/CHV, the only platforms whose format lists include alpha formats. Assisted-by: Claude:claude-opus-4-8 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Leandro Ribeiro <leandro.ribeiro@collabora.com> Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16623 Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20260715054221.451421-1-chaitanya.kumar.borah@intel.com
2026-07-15drm/etnaviv: check MMUv2 status after resetLucas Stach
A full GPU reset is the only way to disable the MMUv2 and the driver depends on the MMU being disabled after a reset to be able to properly restart the GPU. Validate this assumption by checking that the reset actually did disable the MMU. Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com> Link: https://patch.msgid.link/20260511085148.652256-2-l.stach@pengutronix.de Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
2026-07-15drm/etnaviv: check all modules for idle after resetLucas Stach
While the FE is an important part of the GPU, which needs to be idle after reset, all other modules should be idle after a proper reset. Check all present modules for being idle to determine whether the reset was successful. Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com> Link: https://patch.msgid.link/20260511085148.652256-1-l.stach@pengutronix.de Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
2026-07-15Merge tag 'kvmarm-fixes-7.2-2' of ↵Paolo Bonzini
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD KVM/arm64 fixes for 7.2, take #2 - Move locking for kvm_io_bus_get_dev() into the caller, ensuring race-free checks that the returned object is of the correct type - Fix initialisation of the page-table walk level when relaxing permissions - Correctly update the XN attribute when relaxing permissions - Fix the sign extension of loads from emulated MMIO regions - Assorted collection of fixes for pKVM's FFA proxy, together with a couple of FFA driver adjustments
2026-07-15mmc: Merge branch fixes into nextUlf Hansson
Merge the mmc fixes for v7.2-rc[n] into the next branch, to allow them to get tested together with the mmc changes that are targeted for the next release. Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-07-15mmc: dw_mmc: move declaration of dw_mci_pmopsBen Dooks
The dw_mci_pmops is exported out of dw_mmc.c so move the declaration of ton dw_mmc.h from dw_mmc-pltfm.h to fix the following sparse warning: drivers/mmc/host/dw_mmc.c:3512:25: warning: symbol 'dw_mci_pmops' was not declared. Should it be static? Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-07-15drm/i915/bw: introduce the peak bandwidth thresholdVinod Govindapillai
On Xe3+, the SoC can lower the fabric frequency when the display needs less bandwidth than the minimum GV point. This threshold is defined as 20 GB/s. The driver can choose to request this threshold when the required data rate falls below it. Add an extra QGV entry, with both peak bw and derated bw set to 20 GB/s, to the bandwidth info when all of the following hold: 1. The platform is Xe3+. 2. There is at least one existing QGV point. 3. The number of QGV points is below 8 (the maximum). Once a plane group is found, the driver iterates over all QGV points in that group to find the best match for the required data rate. If the required data rate is below 20 GB/s, it selects the peak bw from this new QGV point (20 GB/s). v2: add the peak bandwidth threshold as an additional QGV entry v3: drm_warn switched to drm_dbg_kms (Suraj) Removed log in case of no sagv and some tweak in the log message if the system has already the maximum number of QGV points Bspec: 68880 Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260615203355.218578-8-vinod.govindapillai@intel.com
2026-07-15mmc: sdhci-esdhc-imx: fix resume error handlingLuke Wang
Check pm_runtime_force_resume() return value in resume. If it fails (clock enable failure), return immediately since accessing hardware registers on an unclocked device would cause a kernel panic. The early return intentionally skips enable_irq() and sdhci_disable_irq_wakeups() because the IRQ handler reads SDHCI_INT_STATUS, which would also fault without clocks. The PM runtime usage counter leak only affects this already-broken device instance and is an acceptable tradeoff to preserve system stability. Remove the return value check for mmc_gpio_set_cd_wake(host->mmc, false) since disable_irq_wake() called internally always returns 0. Also return 0 explicitly on the success path instead of propagating stale return values. Fixes: 676a83855614 ("mmc: host: sdhci-esdhc-imx: refactor the system PM logic") Acked-by: Adrian Hunter <adrian.hunter@intel.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Luke Wang <ziniu.wang_1@nxp.com> Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-07-15mmc: sdhci-esdhc-imx: make non-fatal errors non-blocking in suspendLuke Wang
Make pinctrl_pm_select_sleep_state() and mmc_gpio_set_cd_wake() failures non-fatal in the suspend path. These failures only mean slightly higher power consumption or missing CD wakeup capability, but should not block system suspend. Also change the function to always return 0 on the success path instead of propagating non-fatal warning return values. Fixes: 676a83855614 ("mmc: host: sdhci-esdhc-imx: refactor the system PM logic") Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Luke Wang <ziniu.wang_1@nxp.com> Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-07-15mmc: sdhci-esdhc-imx: use pm_runtime_resume_and_get() in suspendLuke Wang
Replace pm_runtime_get_sync() with pm_runtime_resume_and_get() to simplify error handling. pm_runtime_resume_and_get() automatically drops the usage counter on failure, avoiding the need for a separate pm_runtime_put_noidle() call. If it fails, the device is unclocked and accessing hardware registers would cause a kernel panic, so return the error immediately. Fixes: 676a83855614 ("mmc: host: sdhci-esdhc-imx: refactor the system PM logic") Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Luke Wang <ziniu.wang_1@nxp.com> Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-07-15mmc: sdhci-esdhc-imx: disable irq during suspend to fix unhandled interruptLuke Wang
When using WIFI out-of-band wakeup, an "irq xxx: nobody cared" warning occurs. This happens because the usdhc interrupt is not disabled during system suspend when device_may_wakeup() returns false. The sequence of events leading to this issue: 1. System enters suspend without disabling usdhc interrupt (because device_may_wakeup() returns false for usdhc device) 2. WIFI out-of-band wakeup triggers system resume via GPIO interrupt 3. WIFI sends a Card interrupt before usdhc has fully resumed 4. usdhc is still in runtime suspend state and cannot handle the interrupt properly 5. The unhandled interrupt triggers "nobody cared" warning Fix this by unconditionally disabling the usdhc interrupt during suspend and re-enabling it during resume, regardless of the wakeup capability. This ensures no interrupts are processed during the suspend/resume transition. Fixes: 676a83855614 ("mmc: host: sdhci-esdhc-imx: refactor the system PM logic") Acked-by: Adrian Hunter <adrian.hunter@intel.com> Reviewed-by: Haibo Chen <haibo.chen@nxp.com> Signed-off-by: Luke Wang <ziniu.wang_1@nxp.com> Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-07-15mmc: sdhci-esdhc-imx: restore pinctrl before restoring ios timing on resumeLuke Wang
SDIO devices such as WiFi may keep power during suspend, so the MMC core skips full card re-initialization on resume and directly restores the host controller's ios timing to match the card. For DDR mode, pm_runtime_force_resume() sets DDR_EN before the pin configuration is restored from sleep state. This is related to the SoC IP integration: switching pinctrl setting (changing alt from GPIO to USDHC) impacts the internal loopback path. If pinctrl configures the pad to GPIO function, once DDR_EN is set, the DLL delay will be fixed based on the GPIO function loopback path. When the pinctrl is later changed to USDHC function, the internal loopback path changes, making the original fixed sample point no longer suitable for the current loopback path. This causes persistent read CRC errors on subsequent data transfers. SD/eMMC running in DDR mode are unaffected as they are fully re-initialized from legacy timing after resume. Fix this by restoring the pinctrl state based on current timing mode using esdhc_change_pinstate() before pm_runtime_force_resume(). This ensures the correct pin configuration (e.g., 100/200MHz for UHS modes) is applied before DDR_EN is set. Only restore for non-wakeup devices since wakeup devices kept their active pin state during suspend. Fixes: 676a83855614 ("mmc: host: sdhci-esdhc-imx: refactor the system PM logic") Acked-by: Adrian Hunter <adrian.hunter@intel.com> Reviewed-by: Haibo Chen <haibo.chen@nxp.com> Signed-off-by: Luke Wang <ziniu.wang_1@nxp.com> Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-07-15drm/i915/bw: avoid replicating the update_sagv_status() callsVinod Govindapillai
Now that SAGV status update is consolidated, need to update the SAGV status based on the number of QGV points only once after bw info initialization is done. v2: patch description updated. Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260615203355.218578-7-vinod.govindapillai@intel.com
2026-07-15mmc: sdhci-esdhc-imx: fix esdhc_change_pinstate() to allow default state restoreLuke Wang
esdhc_change_pinstate() checks for pins_100mhz and pins_200mhz at the top of the function and returns -EINVAL if either is not defined. This prevents the default case from ever being reached, which means devices with a sleep pinctrl state but without high-speed pin states (100mhz/ 200mhz) can never restore their default pin configuration. Move the IS_ERR checks for pins_100mhz and pins_200mhz into their respective switch cases. Fixes: 676a83855614 ("mmc: host: sdhci-esdhc-imx: refactor the system PM logic") Acked-by: Adrian Hunter <adrian.hunter@intel.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Luke Wang <ziniu.wang_1@nxp.com> Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-07-15mmc: sdhci-esdhc-imx: restore DLL override for DDR modes on resumeLuke Wang
sdhci_esdhc_imx_hwinit() unconditionally clears ESDHC_DLL_CTRL by writing zero. For SDIO devices that keep power during system suspend and operate in DDR mode, the card remains in DDR timing while the host DLL override configuration is lost. Extract the DLL override setup from esdhc_set_uhs_signaling() into a helper esdhc_set_dll_override(), and call it on the resume path when the card kept power and is using a DDR timing mode. Fixes: 676a83855614 ("mmc: host: sdhci-esdhc-imx: refactor the system PM logic") Acked-by: Adrian Hunter <adrian.hunter@intel.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Haibo Chen <haibo.chen@nxp.com> Signed-off-by: Luke Wang <ziniu.wang_1@nxp.com> Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-07-15drm/i915/bw: extract update_sagv_status()Vinod Govindapillai
Extract the code to update the SAGV status based on the number of QGV points into a separate function and use it. v2: rebase v3: patch description updated Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260615203355.218578-6-vinod.govindapillai@intel.com
2026-07-15drm/i915/bw: Extract icl_init_qgv_info()Vinod Govindapillai
Simplify the initialization of QGV points info by extracting the code to initialize the QGV points info from dram info based on the memory type. This will reduce the complexity of the init QGV info routine as we will be supporting new memory types in future platforms. v2: rebase after Ville's refactoring v3: patch description updated Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260615203355.218578-5-vinod.govindapillai@intel.com
2026-07-15mmc: sdhci-esdhc-imx: remove unnecessary mmc_card_wake_sdio_irq check for ↵Luke Wang
tuning save/restore The tuning save/restore during system PM is conditioned on mmc_card_wake_sdio_irq(), but this check is unrelated to whether tuning values need to be preserved. The actual requirement is that the card keeps power during suspend and the controller is a uSDHC. SDIO devices using out-of-band GPIO wakeup maintain power during suspend but do not set the SDIO IRQ wake flag. In this case the tuning delay values are not saved/restored. Remove the unnecessary mmc_card_wake_sdio_irq() condition from both the suspend save and resume restore paths. Fixes: c63d25cdc59a ("mmc: sdhci-esdhc-imx: Save tuning value when card stays powered in suspend") Acked-by: Adrian Hunter <adrian.hunter@intel.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Haibo Chen <haibo.chen@nxp.com> Signed-off-by: Luke Wang <ziniu.wang_1@nxp.com> Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-07-15RDMA/rxe: Reject unimplemented implicit ODP cleanlyxiongweimin
rxe advertises ODP but not IB_ODP_SUPPORT_IMPLICIT. The reg_user_mr path still contained a dead branch that checked the implicit capability and could never succeed. Return -EOPNOTSUPP for the implicit ODP address range up front so the intent is obvious and the unreachable code is gone. Signed-off-by: xiongweimin <xiongweimin@kylinos.cn> Cc: linux-rdma@vger.kernel.org Cc: Jason Gunthorpe <jgg@nvidia.com> Link: https://patch.msgid.link/20260713010439.331054-1-15927021679@163.com Reviewed-by: Zhu Yanjun <yanjun.zhu@linux.dev> Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-07-15RDMA/addr: fix spelling of guarantees in commentxiongweimin
Correct "guarentees" to "guarantees" when describing work cancel. Signed-off-by: xiongweimin <xiongweimin@kylinos.cn> Link: https://patch.msgid.link/20260714024429.188276-1-15927021679@163.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-07-15drm/i915/display: sagv pre/post plane calls to check pmdemand supportVinod Govindapillai
For pmdemand cases, no need to even calculate the masks based on the qgv points index. Though the current logic avoids setting the registers based on the pmdemand support, some qgv point masks are compared in vain and do nothing. So leave early if pmdemand is supported. Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260615203355.218578-4-vinod.govindapillai@intel.com
2026-07-15drm/i915/pm_demand: introduce HAS_PMDEMAND macroVinod Govindapillai
PM demand feature introduces a new way to set bw, power and performance requirements to pcode from display version 14 onwards. Use an identifiable name as a macro to distinguish the pm demand specific changes in the code. Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260615203355.218578-3-vinod.govindapillai@intel.com
2026-07-15drm/i915/wm: clear the plane ddb_y entries on plane disableVinod Govindapillai
The UV/Y plane DDB entriess are never cleared on sk_wm_plane_disable_noatomic() and can leave stale DDB state for NV12 planes on pre-Gen11 devices Fixes: d34b59d5ba41 ("drm/i915: Add skl_wm_plane_disable_noatomic()") Assisted-by: Copilot:claude-sonnet-4.6 Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260615203355.218578-2-vinod.govindapillai@intel.com
2026-07-15OPP: Fix cleanup orderingGregor Herburger
Commit 173e02d67494 ("OPP: Initialize scope-based pointers inline") added initialization for all pointers. In some cases, the ordering was changed so that *opp_table was initialized after *opp. This also changes the order of the registered cleanup functions. When the cleanup happens, this can cause use-after-free errors when the last reference is released and the release function _opp_kref_release tries to access the already freed opp->opp_table. Initialize *opp_table before *opp again to fix this and ensure the correct cleanup order. Fixes: 173e02d67494 ("OPP: Initialize scope-based pointers inline") Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2026-07-15RDMA/cma: fix spelling of guarantees in commentxiongweimin
Correct "guarentees" to "guarantees" when describing handler teardown. Signed-off-by: xiongweimin <xiongweimin@kylinos.cn> Link: https://patch.msgid.link/20260714024423.188238-1-15927021679@163.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-07-15media: i2c: vd55g1: Add support for vd55g4Benjamin Mugnier
vd55g4 is the same device as vd65g4 but outputs in monochrome instead of RGB. Adapt the driver structure according to this new variant, and add its support. Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by: Benjamin Mugnier <benjamin.mugnier@foss.st.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
2026-07-15media: i2c: vd55g1: Fix manual digital gain on color variantBenjamin Mugnier
Apply digital gain to all channels, each channel representing a color. Cc: stable@vger.kernel.org Fixes: e138e7f00042 ("media: i2c: vd55g1: Add support for vd65g4 RGB variant") Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by: Benjamin Mugnier <benjamin.mugnier@foss.st.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
2026-07-15media: i2c: vd55g1: Remove spurious pad format update on init_state()Benjamin Mugnier
vd55g1_update_pad_fmt() is called in vd55g1_init_state(). But vd55g1_set_pad_fmt(), called at the end of vd55g1_init_state(), also calls vd55g1_update_pad_fmt() itself. Enhance readability and clear confusion by only preparing the format in vd55g1_init_state() and let vd55g1_set_pad_fmt() update it instead, effectively calling it only 1 time instead of 2. Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by: Benjamin Mugnier <benjamin.mugnier@foss.st.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
2026-07-15media: i2c: vd55g1: Fix media bus code initializationBenjamin Mugnier
In the driver initialization, the index of the default media bus code from the supported media bus code array is passed directly to the vd55g1_get_fmt_code() function instead of the proper media bus code. This works correctly as a proper media bus code is set after initialization but could not have been the case. This also resulted in mutliple "Unsupported mbus format" error messages. Retrieve the media bus code from the media bus code array, and pass this media bus code to vd55g1_get_fmt_code() instead of the code index. Rename VD55G1_MBUS_CODE_DEF to VD55G1_MBUS_CODE_IDX_DEF and VD55G1_MODE_DEF to VD55G1_MODE_IDX_DEF while at it to avoid future confusions. Display the guilty error code in warning message. Cc: stable@vger.kernel.org Fixes: e138e7f00042 ("media: i2c: vd55g1: Add support for vd65g4 RGB variant") Signed-off-by: Benjamin Mugnier <benjamin.mugnier@foss.st.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
2026-07-15media: ipu6: Do not free aux device pdata after initRuoyu Wang
ipu6_bus_initialize_device() stores the isys/psys pdata pointer in struct ipu6_bus_device and initializes the auxiliary device. After that point, error unwinding must drop the auxiliary device reference and let ipu6_bus_release() free both the bus device and adev->pdata. The isys and psys init paths already call put_device() when MMU initialization fails, and ipu6_bus_add_device() calls auxiliary_device_uninit() on auxiliary_device_add() failure. Both paths therefore run the bus release callback. The extra kfree(pdata) in the callers can release the same object a second time. Remove the manual pdata frees after the auxiliary device has been initialized. This issue was found by a static analysis checker and confirmed by manual source review. Fixes: cb3117b074ae ("media: intel/ipu6: add IPU auxiliary devices") Signed-off-by: Ruoyu Wang <ruoyuw560@gmail.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
2026-07-15media: i2c: ov8865: Program the sensor on stream startJurison Murati
The sensor registers are only written in the runtime PM resume handler; ov8865_set_fmt() merely stores the requested mode, relying on the sensor being runtime suspended between uses so that the next resume applies it. That assumption breaks when something keeps the sensor powered. On IPU3 platforms, ipu_bridge instantiates the VCM device with a DL_FLAG_PM_RUNTIME device link to the sensor, so a userspace process holding the VCM subdev open (e.g. wireplumber's camera monitor) pins the sensor runtime-active. A subsequent set_fmt() then never reaches the hardware: the sensor keeps streaming the mode programmed on the last resume while the CSI-2 receiver expects the newly negotiated format. On a Surface Book 2 (IPU3, ov8865 + dw9719 VCM), requesting the 3264x2448 mode while the hardware was left programmed for the 1632x1224 binned mode makes ipu3-cio2 report "frame sync error" and "payload length is 10340352, received 2585088" (exactly one binned frame) for every frame, and the inverse case stalls the stream after a single frame. Camera applications end up displaying one bogus frame forever. Program the sensor configuration and apply the control values on stream start instead, where the negotiated mode is always current, and only write the configuration in the runtime PM resume handler when resuming with the stream already started. Signed-off-by: Jurison Murati <eng.juri@gmail.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
2026-07-15media: i2c: ov8865: Drop the runtime PM usage count on stream failureJurison Murati
ov8865_s_stream() takes a runtime PM reference when enabling the stream, but returns without releasing it if ov8865_sw_standby() fails, leaving the reference unbalanced and the sensor powered indefinitely. The same applies to a failure while disabling the stream, in which case the reference acquired at stream start is never dropped. Drop the reference in a single place, both when disabling the stream and on failure, and only update the streaming state on success. Signed-off-by: Jurison Murati <eng.juri@gmail.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
2026-07-15media: bcm2835-unicam: Fix asc leaked in error/remove pathEugen Hristev
v4l2_async_nf_add_fwnode_remote() allocates the asc, which is freed when v4l2_async_nf_cleanup() is called. Call v4l2_async_nf_cleanup() properly in the driver paths. Discovered with kmemleak after rmmod: unreferenced object 0xffff000084526b80 (size 64): comm "modprobe", pid 185, jiffies 4295013512 hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 e8 0d ff bf 00 00 ff ff ................ 40 83 bc 84 00 00 ff ff 60 83 bc 84 00 00 ff ff @.......`....... backtrace (crc ac584083): [<00000000ffb081a7>] kmemleak_alloc+0x38/0x44 [<00000000d2fd9301>] __kmalloc+0x1b0/0x250 [<000000004dd5354d>] __v4l2_async_nf_add_fwnode+0x28/0x9c [<0000000067587657>] __v4l2_async_nf_add_fwnode_remote+0x3c/0x64 Fixes: 392cd78d495f ("media: bcm2835-unicam: Add support for CCP2/CSI2 camera interface") Signed-off-by: Eugen Hristev <ehristev@kernel.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
2026-07-15media: intel: ipu-bridge: add blank line after declarationsHungyu Lin
Add a blank line between the local variable declarations and the following statement in ipu_bridge_get_ivsc_acpi_dev(). Also remove an unnecessary blank line within the declaration block. This addresses a checkpatch.pl warning. No functional change intended. Signed-off-by: Hungyu Lin <dennylin0707@gmail.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
2026-07-15media: i2c: gc0310: Use devm_v4l2_sensor_clk_get()Sanjay Chitroda
Several camera sensor drivers access the "clock-frequency" property directly to retrieve the external clock rate or handle the external clock manually in the driver. While this is valid on a subset of ACPI platforms, implementing this logic directly in drivers is deprecated and can lead to inconsistent behaviour across drivers. This driver supports ACPI platforms only. It currently retrieves the external clock rate from the "clock-frequency" property and fails probing if the rate does not match the expected value, which is the correct policy for ACPI platforms. Switch to using the devm_v4l2_sensor_clk_get() helper to standardise clock handling. This preserves the existing behaviour on ACPI platforms that specify a clock-frequency property without providing a clock. On platforms that provide a clock, the helper will program the clock to the rate specified by clock-frequency, which is also consistent with the driver's expectations. Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
2026-07-15media: platform: amd: fix unmet dependency for VIDEO_V4L2_SUBDEV_APIJulian Braha
Currently, VIDEO_AMD_ISP4_CAPTURE selects VIDEO_V4L2_SUBDEV_API without ensuring MEDIA_CONTROLLER is enabled, causing an unmet dependency: WARNING: unmet direct dependencies detected for VIDEO_V4L2_SUBDEV_API Depends on [n]: MEDIA_SUPPORT [=m] && VIDEO_DEV [=m] && MEDIA_CONTROLLER [=n] Selected by [m]: - VIDEO_AMD_ISP4_CAPTURE [=m] && MEDIA_SUPPORT [=m] && MEDIA_PLATFORM_SUPPORT [=y] && MEDIA_PLATFORM_DRIVERS [=y] && DRM_AMDGPU [=m] && DRM_AMD_ISP [=y] && HAS_DMA [=y] && VIDEO_DEV [=m] Many other options in this subsystem select MEDIA_CONTROLLER, let's do the same here. This unmet dependency bug was detected by kconfirm, a static analysis tool for Kconfig. Fixes: 9a54c285630c ("media: platform: amd: Introduce amd isp4 capture driver") Signed-off-by: Julian Braha <julianbraha@gmail.com> Reviewed-by: Bin Du <bin.du@amd.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
2026-07-15media: v4l2-fwnode: Fix fwnode leak in v4l2_fwnode_parse_linkBiren Pandya
In v4l2_fwnode_parse_link(), the remote endpoint fwnode reference is acquired using fwnode_graph_get_remote_endpoint(). This reference is properly released in the error paths, but it is leaked on the success path. Add the missing fwnode_handle_put() before returning 0 to prevent the reference leak. Signed-off-by: Biren Pandya <birenpandya@gmail.com> Fixes: ca50c197bd96 ("[media] v4l: fwnode: Support generic fwnode for parsing standardised properties") Cc: stable@vger.kernel.org [Sakari Ailus: Fix subject prefix and coding style a little.] Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
2026-07-15media: i2c: rdacm21: Fix missing media_entity_cleanup()Biren Pandya
The driver misses calling media_entity_cleanup() on the probe error path and during remove, leaking resources if probe fails after entity initialization or when the driver is unloaded. Fix this by adding media_entity_cleanup() to the rdacm21_probe() error handling path and to rdacm21_remove(). Fixes: a59f853b3b4b ("media: i2c: Add driver for RDACM21 camera module") Signed-off-by: Biren Pandya <birenpandya@gmail.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
2026-07-15media: ipu-bridge: Add DMI quirk for Dell 16 Premium DA16250Samuele Angioli
The Dell 16 Premium DA16250 (marketed as XPS 16) has its OV02C10 front sensor mounted upside down, like the other Dell XPS models already present in upside_down_sensor_dmi_ids[]. The rotation is reported as 0 in both the SSDB and the _PLD, so without a DMI quirk the image is presented upside down. Add a DMI quirk entry for this model so that a rotation of 180 degrees is reported for its OVTI02C1 sensor. Signed-off-by: Samuele Angioli <samuele.angioli@inspect.it> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
2026-07-15media: ti: vpe: Select V4L2_FWNODE for VIPYemike Abhilash Chandra
The VIP driver uses v4l2_fwnode_endpoint_parse() and the v4l2_async_nf_*() notifier APIs, but its Kconfig entry does not select V4L2_FWNODE. Hence kernel test robot reports: vip.c:3236: undefined reference to `v4l2_async_nf_unregister' vip.c:3237: undefined reference to `v4l2_async_nf_cleanup' vip.c:3339: undefined reference to `v4l2_fwnode_endpoint_parse' vip.c:3346: undefined reference to `v4l2_async_nf_init' vip.c:3348: undefined reference to `__v4l2_async_nf_add_fwnode' vip.c:3357: undefined reference to `v4l2_async_nf_register' Select V4L2_FWNODE, which in turn selects V4L2_ASYNC, providing all the missing symbols. Fixes: fc2873aa4a21 ("media: ti: vpe: Add the VIP driver") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202607031826.vOPABT39-lkp@intel.com/ Signed-off-by: Yemike Abhilash Chandra <y-abhilashchandra@ti.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
2026-07-15media: i2c: imx412: switch to {enable,disable}_streamsElgin Perumbilly
Switch from s_stream to enable_streams and disable_streams callbacks. Signed-off-by: Elgin Perumbilly <elgin.perumbilly@siliconsignals.io> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
2026-07-15media: i2c: imx412: Switch to using the sub-device state lockElgin Perumbilly
Switch to using the sub-device state lock and properly call v4l2_subdev_init_finalize() / v4l2_subdev_cleanup() on probe() / remove(). Signed-off-by: Elgin Perumbilly <elgin.perumbilly@siliconsignals.io> Reviewed-by: Tarang Raval <tarang.raval@siliconsignals.io> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
2026-07-15media: i2c: imx412: Convert to CCI register access helpersElgin Perumbilly
Use the new common CCI register access helpers to replace the private register access helpers in the imx412 driver. This simplifies the driver by reducing the amount of code. Signed-off-by: Elgin Perumbilly <elgin.perumbilly@siliconsignals.io> Reviewed-by: Tarang Raval <tarang.raval@siliconsignals.io> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
2026-07-15media: vicodec: fix out-of-bounds write in FWHT encoderJunrui Luo
vidioc_s_fmt_vid_out() sizes the encoder CAPTURE buffer from the compressed descriptor pixfmt_fwht, whose sizeimage_mult is 3: coded_w * coded_h * 3 + sizeof(struct fwht_cframe_hdr). fwht_encode_frame() encodes one plane per component, and an incompressible plane takes the FWHT_FRAME_UNENCODED path in encode_plane(), copying the plane verbatim. For a 4-component pixel format all four planes are full resolution (width_div == height_div == 1), so a frame that forces every plane through the unencoded fallback writes sizeof(struct fwht_cframe_hdr) + 4 * coded_w * coded_h bytes, overrunning the plane by coded_w * coded_h, which can result in corruption of adjacent kernel heap memory. Bump pixfmt_fwht.sizeimage_mult from 3 to 4, matching the largest components_num among the supported raw formats, so the capture buffer is always large enough for the unencoded fallback. Fixes: 16ecf6dff97c ("media: vicodec: Add support for 4 planes formats") Reported-by: Yuhao Jiang <danisjiang@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Junrui Luo <moonafterrain@outlook.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-07-15gpio: bd72720: make read-only const arrays regs staticColin Ian King
Don't populate the read-only const arrays regs on the stack at run time, instead make them static. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Link: https://patch.msgid.link/20260714170258.186766-1-colin.i.king@gmail.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-07-15drm/bridge: Remove legacy bridge callback supportMaxime Ripard
All bridge drivers have been converted to the atomic variants of the enable, disable, pre_enable, and post_disable callbacks. Remove the deprecated legacy hooks from drm_bridge_funcs, the drm_bridge_is_atomic() helper that was only needed to distinguish between atomic and non-atomic bridges, and the legacy bridge test cases. Since all bridges are now atomic, unconditionally initialize the private object state at attach time. Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Link: https://patch.msgid.link/20260707-drm-all-atomic-bridges-v2-37-21d03cbca446@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>