summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2026-06-30drm/panthor: Fix NPD issue on partial unmap of an evicted BOAkash Goel1-13/+13
This commit fixes the NULL pointer dereference issue that would have happened on the split of GPU mapping due to partial unmap of an evicted BO. There is a logic to handle the partial unmap of huge pages when the GPU mapping is split. That logic was not being completely skipped for the VMA of an evicted BO and that resulted in a NPD possibility for the 'bo->backing.pages' pointer, which is set to NULL when pages of a BO are released on eviction. Following dump was seen when a partial unmap was exercised for an evicted BO. Unable to handle kernel paging request at virtual address 0000000000002000 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=00000008842e8000 [0000000000002000] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP <snip> pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : iova_mapped_as_huge_page+0x20/0x68 [panthor] lr : panthor_gpuva_sm_step_remap+0x39c/0x498 [panthor] sp : ffff800086193920 x29: ffff800086193920 x28: ffff800086193a18 x27: ffff800086193b80 x26: 0000000000400000 x25: 0000000000810000 x24: 0000000000400000 x23: ffff000808af1800 x22: 0000000000a00000 x21: ffff800086193a00 x20: ffff000806fd3f00 x19: 0000000000410000 x18: 00000000ffffffff x17: 0000000000000000 x16: 0000000000000000 x15: ffff800083ce2d83 x14: 0000000000000000 x13: 3120646574636976 x12: 6520303030303138 x11: 2d30303030313420 x10: ffff8000836e6c80 x9 : ffff80007bfc889c x8 : 3fffffffffffefff x7 : ffff8000836e6c80 x6 : 0000000000000000 x5 : ffff00097ef19088 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000010000 x1 : 0000000000000400 x0 : 0000000000000000 Call trace: iova_mapped_as_huge_page+0x20/0x68 [panthor] (P) op_remap_cb.isra.0+0x70/0xb0 __drm_gpuvm_sm_unmap+0xf8/0x1c0 drm_gpuvm_sm_unmap+0x40/0x60 panthor_vm_exec_op+0xa0/0x168 [panthor] panthor_vm_bind_exec_sync_op+0x8c/0xb8 [panthor] panthor_ioctl_vm_bind+0xbc/0x170 [panthor] drm_ioctl_kernel+0xc0/0x140 drm_ioctl+0x20c/0x500 __arm64_sys_ioctl+0xb4/0x118 invoke_syscall+0x5c/0x120 el0_svc_common.constprop.0+0x48/0xf8 do_el0_svc+0x28/0x40 el0_svc+0x38/0x128 el0t_64_sync_handler+0xa0/0xe8 el0t_64_sync+0x198/0x1a0 Code: 8b030021 cb020021 f940b800 d34cfc21 (f8617801) ---[ end trace 0000000000000000 ]--- v2: Fix indentation Fixes: 8e7460eac786 ("drm/panthor: Support partial unmaps of huge pages") Signed-off-by: Akash Goel <akash.goel@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patch.msgid.link/20260623130119.2737003-1-akash.goel@arm.com Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
2026-06-30pinctrl: qcom: Unconditionally mark gpio as wakeup enableSneh Mankad1-4/+4
GPIO interrupts that are wakeup capable need to be forwarded to wakeup capable parent irqchip. This is done via writing to it's wakeup_enable bit. Currently the bit is set only for PDC irqchip by checking skip_wake_irqs. skip_wake_irqs is set to differentiate between parent irqchips MPM and PDC. It is set when the parent irqchip is PDC to inform pinctrl about skipping the IRQ setting up at TLMM. However, the functionality to forward GPIO interrupts during SoC low power mode is needed regardless of which parent irqchip it is. Without the functionality it is impossible for MPM irqchip to detect the GPIO interrupt during SoC low power mode since for MPM irqchip the skip_wake_irqs is always false. Remove skip_wake_irqs condition when setting wakeup enable bit to allow forwarding GPIO interrupts for SoCs using MPM irqchip too. Fixes: 76b446f5b86e ("pinctrl: qcom: handle intr_target_reg wakeup_present/enable bits") Signed-off-by: Sneh Mankad <sneh.mankad@oss.qualcomm.com> Reviewed-by: Maulik Shah <maulik.shah@oss.qualcomm.com> Reviewed-by: Linus Walleij <linusw@kernel.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://patch.msgid.link/20260616-enable_wakeup_capable_gpios-v3-1-fb59647d89cb@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-06-30gpio: mt7621: be sure IRQ domain is created before exposing GPIO chipsSergio Paracuellos1-6/+6
Function 'mediatek_gpio_bank_probe()' registers three GPIO chips using 'devm_gpiochip_add_data()'. At this point, the chips become live and visible to consumers. However, the IRQ domain isn't allocated and set up until 'mt7621_gpio_irq_setup()' is called after the GPIO chips setup finishes. If a consumer requests a GPIO IRQ concurrently 'mt7621_gpio_to_irq()' can be called and pass a NULL irq domain pointer irq_create_mapping(), that can corrupt the mappings or cause a crash. Fix this possible problem seting up irq domain before GPIO chips setup is performed. Cc: stable@vger.kernel.org Reported-by: Sashiko <sashiko-bot@kernel.org> Fixes: a46f2e5720f5 ("gpio: mt7621: fix interrupt banks mapping on gpio chips") Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com> Link: https://patch.msgid.link/20260626060112.2498324-4-sergio.paracuellos@gmail.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-06-30gpio: mt7621: more robust management of IRQ domain teardownSergio Paracuellos1-8/+7
The driver uses devm_gpiochip_add_data() to register the GPIO chips which means the devres subsystem will unregister them only after the function 'mt7621_gpio_remove()' returns. During the window between domain destruction and devres unregistering the GPIO chips, the chips are still fully active. If a consumer or userspace invokes gpiod_to_irq() during this window, 'mt7621_gpio_to_irq()' can dereference the already-freed irq domain pointer. Thus, manage the IRQ domain teardown using 'devm_add_action_or_reset()' to guarantee it is destroyed strictly after the GPIO chips are removed. Cc: stable@vger.kernel.org Reported-by: Sashiko <sashiko-bot@kernel.org> Fixes: a46f2e5720f5 ("gpio: mt7621: fix interrupt banks mapping on gpio chips") Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com> Link: https://patch.msgid.link/20260626060112.2498324-3-sergio.paracuellos@gmail.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-06-30gpio: mt7621: avoid corruption of shared interrupt trigger stateSergio Paracuellos1-0/+2
The bank-shared fields like 'rising' and 'falling' are modified using non-atomic read-modify-write operations. Since every gpio chip instance represents an entire bank of 32 pins, if 'mediatek_gpio_irq_type()' is called concurrently for different IRQs on the same bank a possible overwrite of each other's configuration is possible. Thus, protect this state with 'gpio_generic_lock_irqsave' lock in the same way it is handled in irp_chip 'mediatek_gpio_irq_mask()' and 'mediatek_gpio_irq_unmask()' callbacks. Cc: stable@vger.kernel.org Reported-by: Sashiko <sashiko-bot@kernel.org> Fixes: 4ba9c3afda41 ("gpio: mt7621: Add a driver for MT7621") Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com> Link: https://patch.msgid.link/20260626060112.2498324-2-sergio.paracuellos@gmail.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-06-30pinctrl: qcom: Drop unused irq_data argument from ↵Hans de Goede1-4/+3
msm_gpio_update_dual_edge_pos() The "struct irq_data *d" argument to msm_gpio_update_dual_edge_pos() is unused, drop it. Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Acked-by: Linus Walleij <linusw@kernel.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Link: https://patch.msgid.link/20260623122732.6439-2-johannes.goede@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-06-30pinctrl: qcom: Drop unnecessary bitmap_fill() callHans de Goede1-2/+0
Drop an unnecessary bitmap_fill() call from msm_gpio_irq_init_valid_mask(), this is unnecessary because gpiochip_allocate_mask() already does this. Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Acked-by: Linus Walleij <linusw@kernel.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Link: https://patch.msgid.link/20260623122732.6439-1-johannes.goede@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-06-30drm/panthor: Keep interrupts masked until they are neededBoris Brezillon5-10/+18
The autogenerated panthor_request_xx_irq() helpers unmask Mali interrupts before we're sure we'll have a handler registered. For non-shared IRQ lines, that's fine, but for shared ones, it might cause an interrupt flood if the HW block raises an interrupt for any reason. We could reworking the calls in panthor_request_xx_irq(), but it's just simpler to let the caller decide when they are ready to handle interrupts and call panthor_pwr_irq_resume() themselves. While at it, rework the prototype to let users call panthor_pwr_irq_enable_events() explicitly instead of passing an initial mask to panthor_request_pwr_irq(). Fixes: 5fe909cae118 ("drm/panthor: Add the device logical block") Reported-by: Shashiko <sashiko-bot@kernel.org> Closes: https://sashiko.dev/#/patchset/20260623-panthor-signal-from-irq-v3-0-2ece396f8ee0@collabora.com?part=3 Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Karunika Choo <karunika.choo@arm.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patch.msgid.link/20260625-panthor-misc-fixes-v1-11-b67ed973fea6@collabora.com
2026-06-30drm/panthor: Interrupt group start/resumption if group_bind_locked() failsBoris Brezillon1-1/+7
group_bind_locked() can fail if the MMU block is stuck. This is normally a reset situation, but by the time we reset the GPU, we might have tried to resume a group that's not resident, which will probably trip out the FW. So let's avoid that by bailing out when group_bind_locked() returns an error. We don't even try to start more groups because the GPU will be reset anyway. Fixes: de8548813824 ("drm/panthor: Add the scheduler logical block") Reported-by: sashiko-bot@kernel.org Closes: https://sashiko.dev/#/patchset/20260623-panthor-signal-from-irq-v3-0-2ece396f8ee0@collabora.com?part=7 Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patch.msgid.link/20260625-panthor-misc-fixes-v1-10-b67ed973fea6@collabora.com
2026-06-30drm/panthor: Fix a leak when a group is evicted before the tiler OOM is servicedBoris Brezillon1-1/+2
A group ref is tied to the pending tiler_oom_work, so we need to release it if the cancel was effective. Fixes: de8548813824 ("drm/panthor: Add the scheduler logical block") Reported-by: sashiko-bot@kernel.org Closes: https://sashiko.dev/#/patchset/20260623-panthor-signal-from-irq-v3-0-2ece396f8ee0@collabora.com?part=7 Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patch.msgid.link/20260625-panthor-misc-fixes-v1-9-b67ed973fea6@collabora.com
2026-06-30drm/panthor: Drop a needless check in panthor_fw_unplug()Boris Brezillon1-3/+1
panthor_fw_unplug() is only called if we at least managed to initialize the IRQ, so it's safe to drop the "is IRQ initialized" check. Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patch.msgid.link/20260625-panthor-misc-fixes-v1-8-b67ed973fea6@collabora.com
2026-06-30drm/panthor: Fix panthor_pwr_unplug()Boris Brezillon1-1/+2
We can't call panthor_pwr_irq_suspend() if the device is suspended, or this leads to a hang when the IOMEM region is accessed while the clks are disabled. Do what other sub-components do and conditionally call panthor_pwr_irq_suspend() if we know the PWR regbank block is accessible. Fixes: c27787f2b77f ("drm/panthor: Introduce panthor_pwr API and power control framework") Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patch.msgid.link/20260625-panthor-misc-fixes-v1-7-b67ed973fea6@collabora.com
2026-06-30drm/panthor: Don't overrule pending immediate ticks in sched_resume_tick()Boris Brezillon1-1/+8
We schedule immediate ticks when we need to process events on CSGs, but those immediate ticks don't change the resched_target because we want the other groups to stay scheduled for the remaining of the GPU timeslot they were given. Make sure these immediate ticks don't get overruled by a sched_queue_delayed_work() that would delay the tick execution. Fixes: 99820b4b7e50 ("drm/panthor: Make sure we resume the tick when new jobs are submitted") Reported-by: sashiko-bot@kernel.org Closes: https://sashiko.dev/#/patchset/20260625-panthor-signal-from-irq-v4-0-3d2908912afa@collabora.com?part=9 Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Karunika Choo <karunika.choo@arm.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patch.msgid.link/20260625-panthor-misc-fixes-v1-6-b67ed973fea6@collabora.com
2026-06-30drm/panthor: Fix theoretical IOMEM access in suspended stateBoris Brezillon1-3/+7
In theory, our hardirq handler can be called while the device (and thus the panthor_irq) is suspended, because the IRQ line is shared. In practice though, in all the designs we've seen, the line is only shared within the GPU, and because sub-component suspend state is consistent (all-suspended or all-resumed), we shouldn't end up with an interrupt triggered while we're suspended. Fix the problem anyway, if nothing else, for our sanity. Fixes: 0b2d86670a84 ("drm/panthor: Rework panthor_irq::suspended into panthor_irq::state") Reported-by: sashiko-bot@kernel.org Closes: https://sashiko.dev/#/patchset/20260625-panthor-signal-from-irq-v4-0-3d2908912afa@collabora.com?part=1 Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patch.msgid.link/20260625-panthor-misc-fixes-v1-5-b67ed973fea6@collabora.com
2026-06-30drm/panthor: Fix potential invalid pointer deref in group_process_tiler_oom()Boris Brezillon1-1/+4
If heaps is an ERR_PTR(), panthor_heap_pool_put() will deref an invalid pointer. Make sure we set it to NULL in that case. Fixes: de8548813824 ("drm/panthor: Add the scheduler logical block") Reported-by: sashiko-bot@kernel.org Closes: https://sashiko.dev/#/patchset/20260625-panthor-signal-from-irq-v5-0-8836a74e0ef9@collabora.com?part=2 Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patch.msgid.link/20260625-panthor-misc-fixes-v1-4-b67ed973fea6@collabora.com
2026-06-30drm/panthor: Keep the reset work disabled until everything is initializedBoris Brezillon1-0/+4
The reset work will sub-component reset helpers, which might not be ready if the reset happens during initialization, leading to NULL pointer dereferences or worse. Avoid that by keeping the reset work disabled while we're initializing those sub-components. Fixes: 5fe909cae118 ("drm/panthor: Add the device logical block") Reported-by: sashiko-bot@kernel.org Closes: https://sashiko.dev/#/patchset/20260625-panthor-signal-from-irq-v5-0-8836a74e0ef9@collabora.com?part=4 Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patch.msgid.link/20260625-panthor-misc-fixes-v1-2-b67ed973fea6@collabora.com
2026-06-30drm/panthor: Always use the IRQ-safe variant when acquiring the fence lockBoris Brezillon1-43/+38
Since dma_fence objects can be shared with other subsystems, they may be accessed from hardirq context in those drivers, and we have to take that into account by also using the IRQ-safe variant when acquiring the lock. While at it, switch to the guard model. Fixes: de8548813824 ("drm/panthor: Add the scheduler logical block") Reported-by: sashiko-bot@kernel.org Closes: https://sashiko.dev/#/patchset/20260625-panthor-signal-from-irq-v5-0-8836a74e0ef9@collabora.com?part=11 Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patch.msgid.link/20260625-panthor-misc-fixes-v1-1-b67ed973fea6@collabora.com
2026-06-30drm/arm/komeda: fix error handling for clk_prepare_enable() and callersGustavo Kenji Mendonça Kaneko2-6/+14
komeda_dev_resume() calls clk_prepare_enable() without checking the return value. If the clock fails to enable, the function returns 0 (success) while IRQs are enabled and IOMMU is connected on potentially unclocked hardware, causing undefined behavior on resume. Propagate the error from clk_prepare_enable() and fix all call sites in komeda_drv.c that previously ignored the return value of komeda_dev_resume(): - komeda_platform_probe(): if resume fails, jump to err_destroy_mdev (skipping the suspend call, since the clock was never enabled) - komeda_pm_resume(): propagate the error and skip drm_mode_config_helper_resume() on failure This issue was found by code review without access to Komeda hardware. Signed-off-by: Gustavo Kenji Mendonça Kaneko <kaneko.dev@pm.me> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patch.msgid.link/20260609130828.1066038-1-kaneko.dev@pm.me Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
2026-06-30drm/arm/malidp: use clk_bulk API in runtime PM resume and suspendGustavo Kenji Mendonça Kaneko1-6/+16
malidp_runtime_pm_resume() calls clk_prepare_enable() three times without checking the return value. If any clock fails to enable, the driver silently proceeds with unclocked hardware, leading to undefined behavior. Convert both the resume and suspend paths to use the clk_bulk API: clk_bulk_prepare_enable() in resume checks the return value and rolls back any successfully enabled clocks on failure; clk_bulk_disable_unprepare() in suspend keeps the two paths symmetric. This issue was found by code review without access to Mali DP hardware. Signed-off-by: Gustavo Kenji Mendonça Kaneko <kaneko.dev@pm.me> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patch.msgid.link/20260609130812.1065699-1-kaneko.dev@pm.me Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
2026-06-30PCI: rzg3s-host: Add support for RZ/V2H(P) SoCLad Prabhakar1-0/+181
Add support for the RZ/V2H(P) SoC PCIe controllers to the rzg3s-host driver. The RZ/V2H(P) SoC features two independent PCIe controllers that share four physical lanes. The hardware supports two configuration modes: single x4 mode where the first controller uses all four lanes, or dual x2 mode where both controllers use two lanes each. Introduce a setup_lanes() function pointer to configure the PCIe lanes based on the hardware instance. Implement rzv2h_pcie_setup_lanes() to detect the configuration at boot time and program the lane mode via the system controller. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Tested-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Reviewed-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Link: https://patch.msgid.link/20260629220932.861445-5-prabhakar.mahadev-lad.rj@bp.renesas.com
2026-06-30PCI: rzg3s-host: Prepare System Controller handling for multiple controllersLad Prabhakar1-15/+33
Prepare the driver to handle multiple PCIe controllers with distinct System Controller (SYSC) register sets, as required by RZ/V2H(P). The current design stores a single sysc_info structure per SoC, which is insufficient for multi-controller configurations. Introduce controller identifiers and extend struct rzg3s_pcie_soc_data to hold a sysc_info array indexed per PCIe controller. Add a controller_id field to struct rzg3s_pcie_host and select the appropriate System Controller information during probe based on the hardware instance. Keep existing single-controller SoCs functionally unchanged while preparing the driver for RZ/V2H(P) multi-controller support. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Tested-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Reviewed-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Link: https://patch.msgid.link/20260629220932.861445-4-prabhakar.mahadev-lad.rj@bp.renesas.com
2026-06-30PCI: rzg3s-host: Use shared reset controls for power domain resetsLad Prabhakar1-3/+3
Switch to shared reset controls for PCIe power resets to prepare for RZ/V2H(P) support. On this platform, multiple PCIe controllers share the same reset line, requiring shared ownership of the reset control. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Tested-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Reviewed-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Link: https://patch.msgid.link/20260629220932.861445-3-prabhakar.mahadev-lad.rj@bp.renesas.com
2026-06-30pinctrl: qcom: spmi-gpio: Add PMG1110 GPIO supportFenglin Wu1-0/+1
Add PMG1110 GPIO support with its compatible string and match data. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com> Acked-by: Linus Walleij <linusw@kernel.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Linus Walleij <linusw@kernel.org> Link: https://patch.msgid.link/20260610-pmg1110-gpio-v1-2-a9c50cd8b5d9@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-06-30gpio: shared-proxy: always serialize with a sleeping mutexViacheslav Bocharov3-81/+32
The shared GPIO descriptor used either a mutex or a spinlock, chosen at runtime from the underlying chip's can_sleep: shared_desc->can_sleep = gpiod_cansleep(shared_desc->desc); ... if (can_sleep) mutex_lock(); else spin_lock_irqsave(); can_sleep describes only the value path (->get/->set). Under the same lock, however, the proxy may call gpiod_set_config() and gpiod_direction_*(), which can reach pinctrl paths that take a mutex (e.g. gpiod_set_config() -> gpiochip_generic_config() -> pinctrl_gpio_set_config()), independent of can_sleep. On a controller with non-sleeping MMIO value ops the descriptor lock was a spinlock, so the sleeping pinctrl call ran from atomic context. Reproduced on an Amlogic A113X board with the workaround from commit 28f240683871 ("pinctrl: meson: mark the GPIO controller as sleeping") reverted; the original Khadas VIM3 report hit the same path: BUG: sleeping function called from invalid context __mutex_lock pinctrl_get_device_gpio_range pinctrl_gpio_set_config gpiochip_generic_config gpiod_set_config gpio_shared_proxy_set_config <- voting spinlock held ... mmc_pwrseq_simple_probe The spinlock existed to take the value vote from atomic context, but the vote and the (possibly sleeping) control operations share the same state and lock, so this scheme cannot serialize config under a mutex and still offer atomic value access. Always serialize the shared descriptor with a mutex instead and mark the proxy a sleeping gpiochip, driving the underlying GPIO through the cansleep value accessors: those are valid for both sleeping and non-sleeping chips, so value access keeps working on fast controllers, at the cost of no longer being atomic. With every vote edge now driven through the cansleep value setter, gpio_shared_proxy_set_unlocked() no longer needs a per-call setter: drop its set_func callback and call gpiod_set_value_cansleep() directly. The shared direction_output path reaches it only once the line is already an output, so driving the value there is equivalent to re-issuing gpiod_direction_output(), without the redundant per-edge re-assertion of drive config and bias. This is observable: consumers gating on gpiod_cansleep() take their sleeping branch on a proxied GPIO (mmc-pwrseq-emmc skips its emergency-restart reset handler; its normal reset is unaffected), and consumers that reject sleeping GPIOs (pwm-gpio, ps2-gpio, ...) would fail to probe. Such atomic users do not share a pin through the proxy, whose purpose is voting on shared reset/enable lines. The same narrowing already applies on Amlogic since that workaround, and rockchip addressed the identical splat per-driver in commit 7ca497be0016 ("gpio: rockchip: Stop calling pinctrl for set_direction"); fixing the proxy addresses the locking error once, for every controller. The lock type was added by commit a060b8c511ab ("gpiolib: implement low-level, shared GPIO support"); the sleeping call under it arrived with the proxy driver. Fixes: e992d54c6f97 ("gpio: shared-proxy: implement the shared GPIO proxy driver") Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Closes: https://lore.kernel.org/all/00107523-7737-4b92-a785-14ce4e93b8cb@samsung.com/ Signed-off-by: Viacheslav Bocharov <v@baodeep.com> Link: https://patch.msgid.link/20260630101545.800625-2-v@baodeep.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-06-30gpu: nova-core: vbios: parse structs via zerocopyNicolás Antinori2-50/+20
Replace the unsafe `kernel::transmute::FromBytes` trait implementation for the `FalconUCodeDescV3`, `PcirStruct`, `BitHeader`, `BitToken`, `NpdeStruct`, `PciRomHeader`, `PmuLookupTableEntry` and `PmuLookupTableHeader` structs with the derivable `zerocopy::FromBytes` trait. This change eliminates the manual unsafe implementations in favor of a derivable trait. When this trait is derived, validity checks are performed at compile time to ensure that the type can safely implement `FromBytes`. Suggested-by: Miguel Ojeda <ojeda@kernel.org> Link: https://github.com/Rust-for-Linux/linux/issues/1241 Signed-off-by: Nicolás Antinori <nico.antinori.7@gmail.com> Link: https://patch.msgid.link/20260629142007.269873-1-nico.antinori.7@gmail.com [acourbot: add `vbios:` prefix to commit title.] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-06-30drm/virtio: fail init on display-info timeoutPengpeng Hou1-4/+10
virtio_gpu_init() sends GET_DISPLAY_INFO when scanouts are present and waits for display_info_pending to clear. If the response never arrives, the wait result is ignored and probe still succeeds. Return -ETIMEDOUT on display-info timeout. Because this happens after virtio_device_ready(), reset the device and tear down modesetting before using the existing vbuf and virtqueue cleanup path. Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: https://patchwork.freedesktop.org/patch/735301/ [dmitry.osipenko@collabora.com: rebase on misc-next]
2026-06-30gpio: tb10x: remove unnecessary bracesIgor Putko1-2/+1
Fix the checkpatch.pl warning by removing unnecessary braces from a single-statement if-block in tb10x_gpio_probe(). Signed-off-by: Igor Putko <igorpetindev@gmail.com> Signed-off-by: Linus Walleij <linusw@kernel.org>
2026-06-30gpio: tb10x: use unsigned int instead of bare unsignedIgor Putko1-1/+1
Fix the checkpatch.pl warning by using 'unsigned int' instead of the bare use of 'unsigned' for the offset parameter in tb10x_gpio_to_irq(). Signed-off-by: Igor Putko <igorpetindev@gmail.com> Signed-off-by: Linus Walleij <linusw@kernel.org>
2026-06-30pinctrl: bcm2835: Don't remove an unregistered GPIO chipDaniel McCarthy1-1/+0
If the devm_pinctrl_register() function fails, bcm2835_pinctrl_probe() calls gpiochip_remove() before gpiochip_add_data() has registered the GPIO chip. This means that upon failure the gpio_chip.gpiodev is NULL resulting in a null pointer dereference inside the gpiochip_remove() function. Remove the unnecessary function call to gpiochip_remove(). No GPIO cleanup is required because the GPIO chip has not yet been registered. Without this change there is potential for a kernel panic upon registration failure Fixes: 266423e60ea1 ("pinctrl: bcm2835: Change init order for gpio hogs") Signed-off-by: Daniel McCarthy <daniel@dragonzap.com> Signed-off-by: Linus Walleij <linusw@kernel.org>
2026-06-30drm/virtio: bound EDID block reads to the response bufferBryam Vargas1-1/+2
virtio_get_edid_block() validates the read offset only against the device-supplied resp->size field, never against the fixed-size resp->edid array. The EDID block index is driven by the device-supplied extension count, so a malicious virtio-gpu backend can advertise a large size together with a high block count and read far past the array into adjacent kernel memory, which is then surfaced in the parsed EDID (an out-of-bounds read / info leak). Also reject any read whose end exceeds the size of the edid array. Conforming EDID responses stay within the array and are unaffected. Fixes: b4b01b4995fb ("drm/virtio: add edid support") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: https://patch.msgid.link/20260620-b4-disp-22bba7bf-v1-1-b95924cee742@proton.me
2026-06-30Merge drm/drm-next into drm-intel-nextJani Nikula6146-108866/+347339
Sync with v7.2-rc1. Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-06-30PNP: Drop unused assignment of pnp_device_id driver dataUwe Kleine-König (The Capable Hub)1-3/+3
The driver explicitly sets the .driver_data member of struct pnp_device_id to zero without relying on that value. Drop these unused assignments. While touching this array simplify the list terminator and align the the array's coding style to what is used most for these. This patch doesn't modify the compiled array, only its representation in source form benefits. The former was confirmed with builds on x86 and arm64. Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> Link: https://patch.msgid.link/0484b30b6935994f5a2d97c55a47a95e1557dd15.1781102535.git.u.kleine-koenig@baylibre.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-06-30pinctrl: aspeed: Split TRST out of the AST2700 SoC1 JTAGM1 groupBilly Tsai1-2/+4
The JTAGM1 group includes the D12 ball carrying the TRST signal, but TRST is optional for a JTAG master and the ball may be needed for other functions on designs that do not wire it. With TRST embedded in the group, such designs cannot use the JTAG master at all. Move D12 into a new JTAGM1TRST group under the same JTAGM1 function so TRST is muxed only when a board requests it. Boards that do use TRST now need to select both the JTAGM1 and JTAGM1TRST groups. Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com> Signed-off-by: Linus Walleij <linusw@kernel.org>
2026-06-30regulator: rtq2208: Remove the unnecessary MTP_SEL propertyMark Brown1-1/+6
ChiYuan Huang <cy_huang@richtek.com> says: This patch series remove the 'richtek,mtp-sel-high' property usage. Link: https://patch.msgid.link/cover.1782444299.git.cy_huang@richtek.com
2026-06-30regualtor: rtq2208: Initiate the default MTP_SEL state by hardware registerChiYuan Huang1-1/+6
Read the initial MTP_SEL state by hardware register to prevent the wrong specified property value from the conflict of hardware pin assignment. Signed-off-by: ChiYuan Huang <cy_huang@richtek.com> Link: https://patch.msgid.link/557e872a87c603a26cf91f0d4448e527afcbbae8.1782444299.git.cy_huang@richtek.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-06-30spi: nxp-fspi: disable runtime PM on probe failuresJiawen Liu1-9/+22
nxp_fspi_probe() enables runtime PM and autosuspend before several operations that can fail. Some failure paths returned directly before the devm cleanup action was installed, leaving runtime PM enabled. Route those failures through a common runtime PM cleanup path. Use pm_runtime_resume_and_get() for the initial clock enable. Signed-off-by: Jiawen Liu <1298662399@qq.com> Link: https://patch.msgid.link/tencent_8FC0B8DFAF4AE67AEBA20548045D53A77707@qq.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-06-30spi: fsl-dspi: clean up after failed suspend and resumeJiawen Liu1-3/+18
dspi_suspend() disabled the IRQ before spi_controller_suspend(), but ignored a suspend failure and kept tearing the device down. Restore the IRQ and return the error if suspend fails. dspi_resume() also left the clock prepared if controller resume or hardware init failed. Route those failures through clock cleanup. Signed-off-by: Jiawen Liu <1298662399@qq.com> Link: https://patch.msgid.link/tencent_427FA55E3D59112524886E9C931CA0F92F06@qq.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-06-30spi: bcmbca-hsspi: return error from failed controller suspendJiawen Liu1-1/+5
spi_controller_suspend() can fail if pending transfers cannot stop. bcmbca_hsspi_suspend() ignored the error and still disabled the PLL and core clocks. Return the error before disabling the clocks. Signed-off-by: Jiawen Liu <1298662399@qq.com> Link: https://patch.msgid.link/tencent_54F5634545908FBA724E758054BF03953808@qq.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-06-30spi: atcspi200: return error from failed controller suspendJiawen Liu1-1/+4
spi_controller_suspend() can fail when the SPI core cannot stop the controller. atcspi_suspend() ignored that error and disabled the controller clock anyway. Return the error before disabling the clock. Signed-off-by: Jiawen Liu <1298662399@qq.com> Link: https://patch.msgid.link/tencent_306FA547FD68D10EE4B2AE9C132060F12F06@qq.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-06-30spi: bcm-qspi: return error from failed controller suspendJiawen Liu1-1/+5
spi_controller_suspend() can fail if the SPI core cannot stop the controller. bcm_qspi_suspend() ignored that error, disabled the controller clock, uninitialized the hardware, and returned success. Return the suspend error before tearing down the clock and hardware state. Signed-off-by: Jiawen Liu <1298662399@qq.com> Reviewed-by: Kamal Dasu <kamal.dasu@broadcom.com> Link: https://patch.msgid.link/tencent_21BF5F9512F56D45FD9018BAF14ED2805808@qq.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-06-30spi: bcm63xx-hsspi: return error from failed controller suspendJiawen Liu1-1/+5
spi_controller_suspend() can fail if the SPI core cannot stop the controller. bcm63xx_hsspi_suspend() ignored that error, disabled the PLL and core clocks, and returned success. Return the suspend error before disabling the clocks. Signed-off-by: Jiawen Liu <1298662399@qq.com> Acked-by: William Zhang <william.zhang@broadcom.com> Link: https://patch.msgid.link/tencent_B5A06807924A77C8690730EBF7A052AABE05@qq.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-06-30spi: bcm63xx: return error from failed controller suspendJiawen Liu1-1/+4
spi_controller_suspend() can fail if the SPI core cannot stop the controller. bcm63xx_spi_suspend() ignored that error, disabled the controller clock, and returned success. Return the suspend error before tearing down the clock. Signed-off-by: Jiawen Liu <1298662399@qq.com> Link: https://patch.msgid.link/tencent_0BD7D4091B90EC17A8B2BA5EBA8803725905@qq.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-06-30dmaengine: switchtec-dma: fix FIELD_GET misuse when programming SE thresholdDavid Carlier1-1/+1
FIELD_GET(SE_THRESH_MASK, thresh) extracts bits [31:23] from thresh and right-shifts them, which is the inverse of the intended operation. Since thresh is derived from se_buf_len / 2 (at most 255), bits [31:23] are always zero, so the SE threshold is never actually programmed into the register. Use FIELD_PREP() instead to correctly left-shift thresh into bits [31:23] of the valid_en_se register, consistent with the FIELD_PREP usage for the perf tuner config just above. Fixes: 30eba9df76ad ("dmaengine: switchtec-dma: Implement hardware initialization and cleanup") Signed-off-by: David Carlier <devnexen@gmail.com> Review-by: Logan Gunthorpe <logang@deltatee.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260317083252.13224-1-devnexen@gmail.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-30crypto: atmel: Use dmaengine_prep_config_sg() APIFrank Li1-7/+3
Using new API dmaengine_prep_config_sg() to simple code. dmaengine_prep_config_sg() does not distinguish between configuration failures and descriptor preparation failures, as both are reported through a NULL return value. Converting both cases to -ENOMEM is therefore acceptable and consistent with the helper's abstraction. In practice, most users only care whether the operation succeeds or fails, and do not depend on the exact errno value returned from this path. Tested-by: Niklas Cassel <cassel@kernel.org> Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260521-dma_prep_config-v7-9-1f73f4899883@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-30PCI: epf-mhi: Use dmaengine_prep_config_single() to simplify codeFrank Li1-36/+16
Use dmaengine_prep_config_single() to simplify pci_epf_mhi_edma_read[_sync]() and pci_epf_mhi_edma_write[_sync](). No functional change. Tested-by: Niklas Cassel <cassel@kernel.org> Acked-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260521-dma_prep_config-v7-8-1f73f4899883@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-30nvmet: pci-epf: Use dmaengine_prep_config_single_safe() APIFrank Li1-26/+4
Use the new dmaengine_prep_config_single_safe() API to combine the configuration and descriptor preparation into a single call. Since dmaengine_prep_config_single_safe() performs the configuration and preparation atomically and the mutex can be removed. Tested-by: Niklas Cassel <cassel@kernel.org> Acked-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260521-dma_prep_config-v7-7-1f73f4899883@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-30nvmet: pci-epf: Remove unnecessary dmaengine_terminate_sync() on each DMA ↵Frank Li1-2/+1
transfer dmaengine_terminate_sync() cancels all pending requests. Calling it for every DMA transfer is unnecessary and counterproductive. This function is generally intended for cleanup paths such as module removal, device close, or unbind operations. Remove the redundant calls for success path and keep it only at error path. Tested-by: Niklas Cassel <cassel@kernel.org> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Acked-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260521-dma_prep_config-v7-6-1f73f4899883@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-30dmaengine: dw-edma: Pass dma_slave_config to dw_edma_device_transfer()Frank Li1-6/+21
Pass dma_slave_config to dw_edma_device_transfer() to support atomic configuration and descriptor preparation when a non-NULL config is provided to device_prep_config_sg(). Tested-by: Niklas Cassel <cassel@kernel.org> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260521-dma_prep_config-v7-5-1f73f4899883@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-30dmaengine: dw-edma: Use new .device_prep_config_sg() callbackFrank Li1-5/+9
Use the new .device_prep_config_sg() callback to combine configuration and descriptor preparation. No functional changes. Tested-by: Niklas Cassel <cassel@kernel.org> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260521-dma_prep_config-v7-4-1f73f4899883@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-30PCI: endpoint: pci-epf-test: Use dmaengine_prep_config_single() to simplify codeFrank Li1-6/+2
Use dmaengine_prep_config_single() to simplify code. No functional change. Tested-by: Niklas Cassel <cassel@kernel.org> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Acked-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260521-dma_prep_config-v7-3-1f73f4899883@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
generated by cgit (git 2.54.0.dirty) at 2026-09-30 19:53:05 +0000