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

[Will Deacon]

On Mon, Oct 05, 2026 at 03:02:29PM +0700, Bui Duc Phuc wrote:
> > > > 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.
> > > >
> > >
> > > My understanding is that the driver is designed to be generic and
> > > support various hardware configurations, some with this resource (IRQ,
> > > GPIO, clock, ...) and some without.
> > >
> > > If a configuration describes the resource, it means the board is
> > > designed to use it. For that hardware the "optional" nature of the
> > > driver no longer applies, so if we fail to get the resource the error
> > > should be returned.
> > >
> > > A log alone is easy to miss, and the root cause still has to be found
> > > and fixed later anyway. Failing the probe makes the problem visible
> > > right away, when the board is being brought up.
> >
> > If you're doing bring-up, you should probably pay attention to the logs.
> 
> OK. Then we should probably write it as:
> -------------------------------------------------------------------------
> irq = platform_get_irq_optional(pdev, 0);
> if (irq < 0 && irq != -ENXIO)
>         return dev_err_probe(pdev, irq, "failed to get irq\n");

Won't this bail on errors != ENXIO and != EPROBE_DEFER? I think we should
only bail on EPROBE_DEFER. That's also more robust to changes in the error
codes that platform_get_irq_optional() can return.

> -------------------------------------------------------------------------
> 
> > If you're trying to use the device, you probably don't care about the
> > interrupt.
> 
> If we're worried about returning an error here because it might cause
> the device probe to fail, then shouldn't we hide errors from all
> the other functions in probe() as well? :-)

Not really. Only the irq is optional; we really can't continue if something
like ioremap() fails.

Will