Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [High] Timeout paths in GPU and PWR requests return early without clearing pending flags, permanently breaking subsequent requests. -- --- Patch [3]: [PATCH v4 3/3] drm/panthor: Take reqs_lock in soft_reset for clearing pending_reqs --- commit d885508a531cdec1cd82fefa1c02cfc762aa4b05 Author: Nicolas Frattaroli <[email protected]> drm/panthor: Take reqs_lock in soft_reset for clearing pending_reqs This commit adds a missing lock around the clearing of pending_reqs in panthor_gpu_soft_reset(). > diff --git a/drivers/gpu/drm/panthor/panthor_gpu.c > b/drivers/gpu/drm/panthor/panthor_gpu.c > index 55e33f145b40b..fb2702e1e0a2e 100644 > --- a/drivers/gpu/drm/panthor/panthor_gpu.c > +++ b/drivers/gpu/drm/panthor/panthor_gpu.c > @@ -424,7 +424,10 @@ int panthor_gpu_soft_reset(struct panthor_device *ptdev) > return -ETIMEDOUT; > } [Severity: High] This is a pre-existing issue, but does returning early here permanently wedge the state machine? If a hardware timeout occurs, this path returns -ETIMEDOUT and bypasses the cleanup of pending_reqs. Subsequent calls to panthor_gpu_soft_reset() will then hit the drm_WARN_ON for GPU_IRQ_RESET_COMPLETED, skip issuing the actual hardware command, and inevitably time out again. Similar issues appear to exist in the timeout paths for panthor_gpu_flush_caches() and panthor_pwr_reset() where early returns bypass clearing the pending flags. > > - ptdev->gpu->pending_reqs = 0; > + scoped_guard(spinlock, &ptdev->gpu->reqs_lock) { > + ptdev->gpu->pending_reqs = 0; > + } > + > return 0; > } -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=3
