Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] drm/panfrost: Unhandled pm_runtime_get_sync() failure causes bus fault on teardown --
commit 66f46645f69f978e0ed345266812912523ba84f8 Author: Adrián Larumbe <[email protected]> drm/panfrost: Fix PM refcnt and autosuspend issues at device probe/remove During device probe(), failure to do a PM get() will leave the usage_count set to 0, which is the value assigned at device creation time. That means when the autosuspend delay expires, runtime suspend callback won't be invoked, so the device will remain powered on forever. > diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c > b/drivers/gpu/drm/panfrost/panfrost_drv.c > index dd80ad1a67004..2519d76666a98 100644 > --- 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); > + pm_runtime_dont_use_autosuspend(pfdev->base.dev); > pm_runtime_disable(pfdev->base.dev); > panfrost_device_fini(pfdev); [Severity: High] Does this code ignore a potential failure from pm_runtime_get_sync()? If panfrost_remove() is invoked while the device is runtime-suspended, it calls pm_runtime_get_sync() to wake the device up and restore clocks and power before tearing down hardware. If this resume fails, the error appears to be ignored. The code proceeds unconditionally to panfrost_device_fini(), which eventually calls panfrost_gpu_power_off(): drivers/gpu/drm/panfrost/panfrost_gpu.c:panfrost_gpu_power_off() { ... gpu_write(pfdev, SHADER_PWROFF_LO, pfdev->features.shader_present); ... } If the clocks and power are actually off due to the resume failure, will this direct write to GPU MMIO registers cause a synchronous external abort and a kernel panic? A follow-up patch 09/15 in this series adds a drm_WARN_ON around the pm_runtime_get_sync() call, but it still ignores the failure and proceeds to hardware teardown, failing to resolve the potential crash. > 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
