This is not a bug per-se, because this lock is never taken in an interrupt context, but it's not consistent with the other users of this lock. We're also planning on transitioning GPU event processing to a hard handler. Again, this alone wouldn't justify using the IRQ-safe variant, because then this _lock/unlock sequence would be in the hard-IRQ path, where IRQs are already disabled, but let's do it anyway, to keep things consistent.
While at it, transition to a guard() instead of a plain lock/unlock sequence. Signed-off-by: Boris Brezillon <[email protected]> --- drivers/gpu/drm/panthor/panthor_gpu.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/panthor/panthor_gpu.c b/drivers/gpu/drm/panthor/panthor_gpu.c index d0be758ea3e1..b9c51f8a051d 100644 --- a/drivers/gpu/drm/panthor/panthor_gpu.c +++ b/drivers/gpu/drm/panthor/panthor_gpu.c @@ -110,12 +110,11 @@ static void panthor_gpu_irq_handler(struct panthor_irq *pirq, u32 status) if (status & GPU_IRQ_PROTM_FAULT) drm_warn(&ptdev->base, "GPU Fault in protected mode\n"); - spin_lock(&ptdev->gpu->reqs_lock); + guard(spinlock_irqsave)(&ptdev->gpu->reqs_lock); if (status & ptdev->gpu->pending_reqs) { ptdev->gpu->pending_reqs &= ~status; wake_up_all(&ptdev->gpu->reqs_acked); } - spin_unlock(&ptdev->gpu->reqs_lock); } static irqreturn_t panthor_gpu_irq_threaded_handler(int irq, void *data) -- 2.54.0
