Re: [PATCH v4 3/3] drm/panthor: Take reqs_lock in soft_reset for clearing pending_reqs

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