Re: [PATCH] perf/arm-smmuv3: Propagate errors from optional IRQ lookup

[Will Deacon <will@kernel.org>]

On Sat, Oct 03, 2026 at 06:11:52PM +0700, Bui Duc Phuc wrote:
> Hi Will,
> 
> > > > Not sure about this. If it's optional, why should we bail the probe if
> > > > we don't manage to get an irq? Surely it's better to continue without
> > > > the interrupt in that case?
> > > >
> > >
> > > platform_get_irq_optional() returns -ENXIO when no IRQ is available.
> > > Other negative return values indicate errors, including -EPROBE_DEFER.
> > > In the case of -EPROBE_DEFER, we should propagate the error so that
> > > the probe can be retried later.
> >
> > Thanks, The -EPROBE_DEFER case seems more compelling, so perhaps we should
> > check for the expliitly (because it won't fail the probe altogether)?
> >
> 
> The idea of the _optional getters is that only the "not present" case
> is turned into a special value (-ENXIO here, NULL for
> devm_clk_get_optional()), while real errors are still reported to the
> caller.
> 
> Besides -EPROBE_DEFER, platform_get_irq_optional() can return other
> negative error values depending on how the IRQ is obtained. These
> indicate an actual error rather than the IRQ simply being absent.
> Ignoring them would leave the device running without its interrupt
> and no indication of what went wrong.
>
> 
> So I'd rather keep:
> 
> -----------------------------------------------------
> irq = platform_get_irq_optional(pdev, 0);
> if (irq < 0 && irq != -ENXIO)
>         return irq;
> -----------------------------------------------------
> 
> and continue without the IRQ only for -ENXIO. This is also the usual
> pattern for platform_get_irq_optional() users.

Sorry, but how is failing the probe possibly better than continuing without
the optional interrupt? Add a diagnostic if you like, but aborting the probe
feels completely unnecessary to me.

Will