On Tue, Dec 02, 2025 at 01:04:24PM -0800, Matthew Brost wrote:
> On Tue, Dec 02, 2025 at 09:47:39PM +0100, Andi Shyti wrote:
> > Hi Matt,
> >
> > > > @@ -93,9 +92,8 @@ void xe_hw_fence_irq_finish(struct xe_hw_fence_irq
> > > > *irq)
> > > > spin_lock_irqsave(&irq->lock, flags);
> > > > list_for_each_entry_safe(fence, next, &irq->pending,
> > > > irq_link) {
> > > > list_del_init(&fence->irq_link);
> > > > - err = dma_fence_signal_locked(&fence->dma);
> > > > +
> > > > XE_WARN_ON(dma_fence_check_and_signal_locked(&fence->dma));
> > >
> > > I think XE_WARN_ON can compile out in certain builds. Best to leave warn
> > > on logic as is.
> >
> > I don't think XE_WARN_ON compiles out. It should always evaluate
> > the content, then, depending on the build, it prints debug logs.
>
> Ah, ok. I thought XE_WARN_ON was tied to a Kconfig to compile out or
> WARN_ON (this is what XE_WARN_ON resolves) compiled out in some kernel
> builds. Upon more looking, I guess neither of these is the case.
>
> So I guess this patch is actually:
> Reviewed-by: Matthew Brost <[email protected]>
and
Acked-by: Rodrigo Vivi <[email protected]>
if needed to merge through any other tree...
>
> Sorry for the noise. Side note, we should probably just XE_WARN_ON too
> since this is just WARN_ON.
>
> Matt
>
> >
> > Andi
