Re: [PATCH v15 06/15] drm/panfrost: Fix PM refcnt and autosuspend issues at device probe/remove

[sashiko-bot@kernel.org]

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 <adrian.larumbe@collabora.com>

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/20261012-claude-fixes-v15-0-bc0a6c498553@collabora.com?part=6