Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] pm_runtime: usage_count corruption on early probe failure --
commit 83a4c1b15f0bb7a999d8fbc11545b9b267d7fbdf Author: Adrián Larumbe <[email protected]> drm/panfrost: Move all DRM device initialisation into device_init() This commit moves DRM device registration and runtime PM setup from panfrost_probe() into panfrost_device_init(), and consolidates the cleanup path into panfrost_device_fini(). > diff --git a/drivers/gpu/drm/panfrost/panfrost_device.c > b/drivers/gpu/drm/panfrost/panfrost_device.c > index 9f2b1967a3984..b8094c0d12528 100644 > --- a/drivers/gpu/drm/panfrost/panfrost_device.c > +++ b/drivers/gpu/drm/panfrost/panfrost_device.c [ ... ] > @@ -311,11 +343,22 @@ int panfrost_device_init(struct panfrost_device *pfdev) > panfrost_reset_fini(pfdev); > out_pm_domain: > panfrost_pm_domain_fini(pfdev); > + > + if (pm_runtime_active(pfdev->base.dev)) { > + pm_runtime_set_suspended(pfdev->base.dev); > + pm_runtime_put_noidle(pfdev->base.dev); > + } > + [Severity: High] Can this catch-all conditional block cause a PM runtime usage_count corruption on early probe failures? If sysfs power/control is set to 'on' (e.g., via udev rules before probe), pm_runtime_forbid() increments the usage_count to 1. If the driver then fails early in panfrost_device_init() (such as a probe deferral during panfrost_clk_init()), pm_runtime_enable() has not been called yet. This leaves dev->power.disable_depth at 1, which inherently causes pm_runtime_active() to return true. This would cause the error path to incorrectly assume the driver acquired the PM reference, calling pm_runtime_put_noidle() and erroneously decrementing the usage_count to 0. When userspace later sets power/control to 'auto', pm_runtime_allow() would decrement the usage_count again, underflowing it to -1 and permanently breaking runtime PM for the device. > return err; > } -- Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=8
