On 12/05/2026 12:37, Boris Brezillon wrote: > 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]>
Reviewed-by: Steven Price <[email protected]> Although this now leaves the lock in panthor_pwr_irq_handler() the odd one out... Thanks, Steve > --- > 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) >
