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

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

[phucduc.bui]

From: bui duc phuc <phucduc.bui@gmail.com>

platform_get_irq_optional() returns a positive IRQ number on success or
a negative error code on failure. For an optional IRQ, -ENXIO indicates
that no optional IRQ is available, while other errors should be propagated.

Propagate all error codes returned by platform_get_irq_optional() other
than -ENXIO.

Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---
 drivers/perf/arm_smmuv3_pmu.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/perf/arm_smmuv3_pmu.c b/drivers/perf/arm_smmuv3_pmu.c
index 621f02a7f43b..6c942697e57f 100644
--- a/drivers/perf/arm_smmuv3_pmu.c
+++ b/drivers/perf/arm_smmuv3_pmu.c
@@ -893,6 +893,8 @@ static int smmu_pmu_probe(struct platform_device *pdev)
 	}
 
 	irq = platform_get_irq_optional(pdev, 0);
+	if (irq < 0 && irq != -ENXIO)
+		return irq;
 	if (irq > 0)
 		smmu_pmu->irq = irq;
 
-- 
2.43.0

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

[Will Deacon]

On Tue, Aug 11, 2026 at 11:19:34AM +0700, phucduc.bui@gmail.com wrote:
> From: bui duc phuc <phucduc.bui@gmail.com>
> 
> platform_get_irq_optional() returns a positive IRQ number on success or
> a negative error code on failure. For an optional IRQ, -ENXIO indicates
> that no optional IRQ is available, while other errors should be propagated.
> 
> Propagate all error codes returned by platform_get_irq_optional() other
> than -ENXIO.
> 
> Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
> ---
>  drivers/perf/arm_smmuv3_pmu.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/perf/arm_smmuv3_pmu.c b/drivers/perf/arm_smmuv3_pmu.c
> index 621f02a7f43b..6c942697e57f 100644
> --- a/drivers/perf/arm_smmuv3_pmu.c
> +++ b/drivers/perf/arm_smmuv3_pmu.c
> @@ -893,6 +893,8 @@ static int smmu_pmu_probe(struct platform_device *pdev)
>  	}
>  
>  	irq = platform_get_irq_optional(pdev, 0);
> +	if (irq < 0 && irq != -ENXIO)
> +		return irq;

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?

Will

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

[Bui Duc Phuc]

Hi Will,

Thank you for your review.

>
> 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.

Best regard,
Phuc

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

[Will Deacon]

On Sat, Oct 03, 2026 at 07:07:12AM +0700, Bui Duc Phuc wrote:
> > 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)?

Will

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

[Bui Duc Phuc]

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.

Best regards,
Phuc

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

[Will Deacon]

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

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

[Bui Duc Phuc]

Hi Will,

>
> 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.

Best regards,
Phuc

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

[Will Deacon]

On Sun, Oct 04, 2026 at 08:49:07PM +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.
If you're trying to use the device, you probably don't care about the
interrupt.

Will

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

[Bui Duc Phuc]

Hi Will,

> > > 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");
-------------------------------------------------------------------------

> 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? :-)

Best regards,
Phuc

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