Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [High] Unconditional hardware register access after pm_runtime_get_sync() fails causes a bus fault. -- commit 21c994e3f1ed58edbfb0311aa1649d2c75eb0938 Author: Adrián Larumbe <[email protected]> drm/panfrost: Add warning messages to fatal error conditions This commit adds warning messages to device removal if it fails to take a PM reference, and to the PM suspend path if it still reports inflight jobs. > diff --git a/drivers/gpu/drm/panfrost/panfrost_device.c > b/drivers/gpu/drm/panfrost/panfrost_device.c > index f6066aef47666..ee4c468b882d4 100644 > --- a/drivers/gpu/drm/panfrost/panfrost_device.c > +++ b/drivers/gpu/drm/panfrost/panfrost_device.c [ ... ] > @@ -367,7 +368,7 @@ int panfrost_device_init(struct panfrost_device *pfdev) > > void panfrost_device_fini(struct panfrost_device *pfdev) > { > - pm_runtime_get_sync(pfdev->base.dev); > + drm_WARN_ON(&pfdev->base, pm_runtime_get_sync(pfdev->base.dev) < 0); [Severity: High] This is a pre-existing issue, but if pm_runtime_get_sync() fails (for example, due to a regulator or clock enable failure during runtime resume), the device remains unclocked and unpowered. If execution continues unconditionally, subsequent teardown sequences like panfrost_device_disable_hw(pfdev) and panfrost_perfcnt_fini(pfdev) will attempt to write to MMIO registers (such as GPU_PERFCNT_CFG). On ARM platforms, writing to MMIO registers of an unpowered or unclocked device typically triggers a synchronous external abort and a kernel panic. Would it be safer to handle the resource acquisition failure by skipping the hardware-accessing teardown steps when the power on fails? > pm_runtime_dont_use_autosuspend(pfdev->base.dev); > pm_runtime_put_noidle(pfdev->base.dev); > pm_runtime_disable(pfdev->base.dev); -- Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=9
