Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] drm/panfrost: fatal bus fault on pm_runtime_get_sync() failure during teardown --
commit b75b37397a751cf9b55bbc2c3a99131de6b299ec Author: Adrián Larumbe <[email protected]> drm/panfrost: Fix PM refcnt and autosuspend issues at device probe/remove This commit manually adjusts the PM usage counter during device probe and removal to ensure autosuspend works correctly. It calls pm_runtime_dont_use_autosuspend() in the wind-down path to fix devfreq spam and job timeouts. > diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c > b/drivers/gpu/drm/panfrost/panfrost_drv.c > --- a/drivers/gpu/drm/panfrost/panfrost_drv.c > +++ b/drivers/gpu/drm/panfrost/panfrost_drv.c [ ... ] > @@ -884,9 +892,12 @@ static void panfrost_remove(struct platform_device *pdev) > drm_dev_unregister(&pfdev->base); > > pm_runtime_get_sync(pfdev->base.dev); [Severity: High] If pm_runtime_get_sync() fails here, could this lead to a fatal bus fault? In panfrost_remove() in drivers/gpu/drm/panfrost/panfrost_drv.c, the return value of pm_runtime_get_sync() is ignored. If the resume operation fails, the device remains in a suspended state with its clocks and power domains disabled. The code then unconditionally calls panfrost_device_fini(), which executes hardware teardown functions like panfrost_jm_fini(), panfrost_mmu_fini(), and panfrost_gpu_fini(). These functions read and write MMIO registers. Accessing unclocked or unpowered MMIO registers on ARM SoC architectures triggers a fatal synchronous external abort (SError) or data abort, which brings down the entire system. Should hardware register accesses be explicitly skipped if power could not be restored? > + pm_runtime_dont_use_autosuspend(pfdev->base.dev); > pm_runtime_disable(pfdev->base.dev); > panfrost_device_fini(pfdev); > pm_runtime_set_suspended(pfdev->base.dev); > + pm_runtime_put_noidle(pfdev->base.dev); > + > } -- Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=6
