[PATCH net-next v5 0/3] net: xilinx: axienet: Fix IRQ error handling

[PATCH net-next v5 0/3] net: xilinx: axienet: Fix IRQ error handling

[phucduc.bui]

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

Hi all,

This series fixes IRQ error handling in the Xilinx AXI Ethernet driver

Handle errors from optional IRQ lookup and preserve the original error
codes instead of returning -ENOMEM.

The changes were found by manual code inspection and compile-tested
only.

Link v1 : 
https://lore.kernel.org/all/20260811034715.6034-1-phucduc.bui@gmail.com/
Link v2 : 
https://lore.kernel.org/all/20260813042012.17631-1-phucduc.bui@gmail.com/
Link v3 :
https://lore.kernel.org/all/20260817105241.63345-1-phucduc.bui@gmail.com/
Link v4 :
https://lore.kernel.org/all/20260821123249.41527-1-phucduc.bui@gmail.com/

Changes in v2 : 
 - Split one patch from v1 into two patches.
Changes in v3 :
 - Move the lp->eth_irq check below instead of handling it immediately 
   after platform_get_irq_optional()
 - Add error handling for platform_get_irq()
Changes in v4 : 
 - Add Reviewed-by tags
 - Add error handling for irq_of_parse_and_map()
Changes in v5 : 
 - Change the error code returned when irq_of_parse_and_map() fails 
   from -ENOMEM to -EINVAL.

Best regards,
Phuc

bui duc phuc (3):
  net: xilinx: axienet: Propagate errors from optional IRQ lookup
  net: xilinx: axienet: Handle optional IRQ return value correctly
  net: xilinx: axienet: Fix IRQ error handling

 drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

-- 
2.43.0

[PATCH net-next v5 1/3] net: xilinx: axienet: 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.

Another call to platform_get_irq_optional() in the same function already
handles the return value this way. Apply the same error handling to this
call site for consistency.

Fixes: d6349e3e14c7 ("net: axienet: Mark eth_irq as optional")
Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---
 drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
index 1722b7038f34..207aecb5f8b9 100644
--- a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
+++ b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
@@ -2975,6 +2975,8 @@ static int axienet_probe(struct platform_device *pdev)
 			dev_err(&pdev->dev, "could not determine irqs\n");
 			return -ENOMEM;
 		}
+		if (lp->eth_irq < 0 && lp->eth_irq != -ENXIO)
+			return lp->eth_irq;
 
 		/* Reset core now that clocks are enabled, prior to accessing MDIO */
 		ret = __axienet_device_reset(lp);
-- 
2.43.0

Re: [PATCH net-next v5 1/3] net: xilinx: axienet: Propagate errors from optional IRQ lookup

[Simon Horman]

On Thu, Sep 03, 2026 at 02:32:50PM +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.
> 
> Another call to platform_get_irq_optional() in the same function already
> handles the return value this way. Apply the same error handling to this
> call site for consistency.
> 
> Fixes: d6349e3e14c7 ("net: axienet: Mark eth_irq as optional")
> Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
> Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>

Reviewed-by: Simon Horman <horms@kernel.org>

[PATCH net-next v5 2/3] net: xilinx: axienet: Handle optional IRQ return value correctly

[phucduc.bui]

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

lp->eth_irq is assigned from platform_get_irq_optional(), which returns
a non-zero interrupt number on success or a negative error number on
failure. Errors other than -ENXIO are handled before this check,
so -ENXIO is the only error value that can reach this point.

Check for a negative value instead of treating 0 as an undefined IRQ.

Fixes: 522856cefaf0 ("net: axienet: Add optional support for Ethernet core interrupt")
Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---
 drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
index 207aecb5f8b9..3927ababf833 100644
--- a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
+++ b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
@@ -3052,7 +3052,7 @@ static int axienet_probe(struct platform_device *pdev)
 		ndev->ethtool_ops = &axienet_ethtool_ops;
 	}
 	/* Check for Ethernet core IRQ (optional) */
-	if (lp->eth_irq <= 0)
+	if (lp->eth_irq < 0)
 		dev_info(&pdev->dev, "Ethernet core IRQ not defined\n");
 
 	/* Retrieve the MAC address */
-- 
2.43.0

Re: [PATCH net-next v5 2/3] net: xilinx: axienet: Handle optional IRQ return value correctly

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found 1 potential
issue(s) to consider:

Critical: 0 · High: 0 · Medium: 1 (1) · Low: 0

- [Medium] net: xilinx: axienet: Handle optional IRQ return value
  correctly — the patch carries a `Fixes: 522856cefaf0` tag and a…

Pre-existing issues:
- [Medium] DT binding vs driver interrupt indexing mismatch (pre-
  existing, not touched by this patch).

--

net: xilinx: axienet: Handle optional IRQ return value correctly

This changes the informational check on lp->eth_irq in axienet_probe()
from "<= 0" to "< 0", on the grounds that platform_get_irq_optional()
never returns 0. The patch carries a Fixes tag pointing at 522856cefaf0.

No Link: tags were present in the commit header.

> diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> index 207aecb5f8b9..3927ababf833 100644
> --- a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> +++ b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> @@ -3052,7 +3052,7 @@ static int axienet_probe(struct platform_device *pdev)
>  		ndev->ethtool_ops = &axienet_ethtool_ops;
>  	}
>  	/* Check for Ethernet core IRQ (optional) */
> -	if (lp->eth_irq <= 0)
> +	if (lp->eth_irq < 0)
>  		dev_info(&pdev->dev, "Ethernet core IRQ not defined\n");

[Severity: Medium]

Is this change a functional no-op, and if so, is the Fixes tag warranted?

The commit message itself states:

    Errors other than -ENXIO are handled before this check,
    so -ENXIO is the only error value that can reach this point.

Combined with platform_get_irq_optional() never returning 0:

drivers/base/platform.c:platform_get_irq_affinity() {
	...
out_not_found:
	ret = -ENXIO;
out:
	if (WARN(!ret, "0 is an invalid IRQ number\n"))
		return -EINVAL;
	...
}

the set of values lp->eth_irq can hold when reaching this dev_info() is
{positive IRQ number, -ENXIO}. Over that set, "<= 0" and "< 0" select
exactly the same values, so no configuration behaves differently before or
after this patch.

Would it be better to drop the Fixes tag, note that no functional change is
intended, and avoid a stable backport of a change with no observable effect?

Alternatively, writing the test as:

	if (lp->eth_irq == -ENXIO)
		dev_info(&pdev->dev, "Ethernet core IRQ not defined\n");

would state the reachable condition directly.

There is also a consistency question. Every other test of this field in
the same file still uses "> 0", for example in axienet_device_reset():

	axienet_iow(lp, XAE_IE_OFFSET, lp->eth_irq > 0 ?

and in axienet_init_legacy_dma():

	if (lp->eth_irq > 0) {
		ret = request_irq(lp->eth_irq, axienet_eth_irq, IRQF_SHARED,

If treating 0 as an undefined IRQ is the problem being addressed, why are
the sites that actually request and enable the interrupt left using the
complementary "> 0" form, making this the only "< 0" test of eth_irq?

[Severity: Medium]

This isn't a bug introduced by this patch, but while looking at where
lp->eth_irq comes from, the interrupt indexing in axienet_probe() and the
binding appear to disagree.

Documentation/devicetree/bindings/net/xlnx,axi-ethernet.yaml describes a
fixed item order:

  interrupts:
    items:
      - description: Ethernet core interrupt
      - description: Tx DMA interrupt
      - description: Rx DMA interrupt
    ...
    minItems: 1

but the branch in axienet_probe() that reads the DMA resources from the
Ethernet node uses:

			lp->rx_irq = platform_get_irq(pdev, 1);
			lp->tx_irq = platform_get_irq(pdev, 0);
			lp->eth_irq = platform_get_irq_optional(pdev, 2);

that is, index 0 = Tx DMA, 1 = Rx DMA, 2 = Ethernet core.

For a device tree written strictly to the binding in that shape, would
axienet_eth_irq() end up bound to a DMA line, and the DMA handlers to the
wrong lines?

The same pair also seems to disagree on minItems: 1, since this path
requires index 1 unconditionally:

		if (!lp->rx_irq || !lp->tx_irq) {
			dev_err(&pdev->dev, "could not determine irqs\n");
			return -EINVAL;
		}

The axistream-connected and dmas paths use platform_get_irq_optional(pdev, 0)
for the Ethernet core interrupt and match the binding, and both yaml
examples are consistent with the driver, so only the
DMA-resources-on-the-Ethernet-node shape looks affected. There is no
in-tree DTS for xlnx,axi-ethernet-* to settle which side is correct.
Should the binding or the driver indexing be corrected in a separate patch?

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260903073252.339250-1-phucduc.bui%40gmail.com

Re: [PATCH net-next v5 2/3] net: xilinx: axienet: Handle optional IRQ return value correctly

[Bui Duc Phuc]

> Critical: 0 · High: 0 · Medium: 1 (1) · Low: 0
>
> - [Medium] net: xilinx: axienet: Handle optional IRQ return value
>   correctly — the patch carries a `Fixes: 522856cefaf0` tag and a…
>

OK, agreed, I'll drop the Fixes tag in this case, since this is a
no-op cleanup rather than an actual behavior fix.


> Pre-existing issues:
> - [Medium] DT binding vs driver interrupt indexing mismatch (pre-
>   existing, not touched by this patch).
>

This is a pre-existing issue, unrelated to this patch. I'll keep this
patch's scope as is.

Re: [PATCH net-next v5 2/3] net: xilinx: axienet: Handle optional IRQ return value correctly

[Simon Horman]

On Tue, Sep 08, 2026 at 09:32:32AM +0700, Bui Duc Phuc wrote:
> > Critical: 0 · High: 0 · Medium: 1 (1) · Low: 0
> >
> > - [Medium] net: xilinx: axienet: Handle optional IRQ return value
> >   correctly — the patch carries a `Fixes: 522856cefaf0` tag and a…
> >
> 
> OK, agreed, I'll drop the Fixes tag in this case, since this is a
> no-op cleanup rather than an actual behavior fix.

Thanks, with that addressed this looks good to me.

Reviewed-by: Simon Horman <horms@kernel.org>

-- 
pw-bot: changes-requested

Re: [PATCH net-next v5 2/3] net: xilinx: axienet: Handle optional IRQ return value correctly

[Bui Duc Phuc]

> > OK, agreed, I'll drop the Fixes tag in this case, since this is a
> > no-op cleanup rather than an actual behavior fix.
>
> Thanks, with that addressed this looks good to me.
>
> Reviewed-by: Simon Horman <horms@kernel.org>
>

Thanks for the review, Simon.
I’ll send the updated version shortly.

[PATCH net-next v5 3/3] net: xilinx: axienet: Fix IRQ error handling

[phucduc.bui]

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

irq_of_parse_and_map() returns 0 when parsing or mapping an IRQ fails,
while platform_get_irq() returns a negative error code on failure.

Handle both failure cases appropriately: return -EINVAL when
irq_of_parse_and_map() fails, and propagate the original error code
returned by platform_get_irq() instead of returning -ENOMEM.

Fixes: 28ef9ebdb64c ("net: axienet: make use of axistream-connected attribute optional")
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---

Changes in v4 : 
 - Add error handling for irq_of_parse_and_map()
Changes in v5 : 
 - Change the error code returned when irq_of_parse_and_map() fails 
   from -ENOMEM to -EINVAL.

 drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
index 3927ababf833..782f903d318f 100644
--- a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
+++ b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
@@ -2971,10 +2971,14 @@ static int axienet_probe(struct platform_device *pdev)
 			dev_err(&pdev->dev, "could not map DMA regs\n");
 			return PTR_ERR(lp->dma_regs);
 		}
-		if (lp->rx_irq <= 0 || lp->tx_irq <= 0) {
+		if (!lp->rx_irq || !lp->tx_irq) {
 			dev_err(&pdev->dev, "could not determine irqs\n");
-			return -ENOMEM;
+			return -EINVAL;
 		}
+		if (lp->rx_irq < 0)
+			return lp->rx_irq;
+		if (lp->tx_irq < 0)
+			return lp->tx_irq;
 		if (lp->eth_irq < 0 && lp->eth_irq != -ENXIO)
 			return lp->eth_irq;
 
-- 
2.43.0

Re: [PATCH net-next v5 3/3] net: xilinx: axienet: Fix IRQ error handling

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found 1 potential
issue(s) to consider:

Critical: 0 · High: 1 · Medium: 0 (1) · Low: 0

- [High] Incomplete fix: the axistream-connected branch of
  axienet_probe() still cannot request a probe retry, and this patch now…

Pre-existing issues:
- [Medium] DT binding and driver disagree on interrupt index ordering.

--

net: xilinx: axienet: Fix IRQ error handling

This changes the DMA IRQ validation in axienet_probe() so that a zero
result from irq_of_parse_and_map() returns -EINVAL instead of -ENOMEM,
and adds explicit propagation of negative error codes coming from
platform_get_irq().

> diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> index 3927ababf833..782f903d318f 100644
> --- a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> +++ b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> @@ -2971,10 +2971,14 @@ static int axienet_probe(struct platform_device *pdev)
>  			dev_err(&pdev->dev, "could not map DMA regs\n");
>  			return PTR_ERR(lp->dma_regs);
>  		}
> -		if (lp->rx_irq <= 0 || lp->tx_irq <= 0) {
> +		if (!lp->rx_irq || !lp->tx_irq) {
>  			dev_err(&pdev->dev, "could not determine irqs\n");
> -			return -ENOMEM;
> +			return -EINVAL;
>  		}

[Severity: High]
Does turning the zero case into a permanent -EINVAL remove the chance of a
probe retry for the axistream-connected branch?

In that branch the IRQs come from:

		lp->rx_irq = irq_of_parse_and_map(np, 1);
		lp->tx_irq = irq_of_parse_and_map(np, 0);

irq_of_parse_and_map() folds every failure into 0, including the case where
the interrupt provider's IRQ domain is not registered yet:

drivers/of/irq.c:irq_of_parse_and_map() {
	if (of_irq_parse_one(dev, index, &oirq))
		return 0;

	return irq_create_of_mapping(&oirq);
}

irq_create_of_mapping() also returns 0 when no domain is found, so
"not ready yet" and "malformed DT" are indistinguishable here, and
axienet_probe() now converts both into a terminal -EINVAL with no
-EPROBE_DEFER path.

Would of_irq_get(np, index) be a better fit? It is documented to return
-EPROBE_DEFER if the IRQ domain is not yet created, and 0 only when the
interrupt is genuinely absent, which would let a single pair of checks

		if (irq < 0)
			return irq;
		if (!irq)
			return -EINVAL;

cover both the axistream and the platform_get_irq() branches.

Could the commit message also mention that the deferral case stays
unhandled with irq_of_parse_and_map(), or use of_irq_get() so that it is?

> +		if (lp->rx_irq < 0)
> +			return lp->rx_irq;
> +		if (lp->tx_irq < 0)
> +			return lp->tx_irq;

Are these two checks reachable for the axistream-connected branch?
irq_of_parse_and_map() returns an unsigned int virq, so they only ever fire
for the values obtained from platform_get_irq(), which makes the added
error handling asymmetric between the two IRQ sources.

>  		if (lp->eth_irq < 0 && lp->eth_irq != -ENXIO)
>  			return lp->eth_irq;
>

[Severity: Medium]
This is a pre-existing issue and was not introduced by this patch, but since
the patch hardens validation on exactly this branch, it may be worth
reconciling: the driver and the binding disagree on the interrupt index
order.

The direct-resource branch of axienet_probe() reads:

		lp->rx_irq = platform_get_irq(pdev, 1);
		lp->tx_irq = platform_get_irq(pdev, 0);
		lp->eth_irq = platform_get_irq_optional(pdev, 2);

Documentation/devicetree/bindings/net/xlnx,axi-ethernet.yaml describes the
opposite positional order:

  interrupts:
    items:
      - description: Ethernet core interrupt
      - description: Tx DMA interrupt
      - description: Rx DMA interrupt

The same probe function treats index 0 on the ethernet node as the Ethernet
core IRQ in the axistream and dmas branches:

		lp->eth_irq = platform_get_irq_optional(pdev, 0);

so index 0 has two meanings inside one function and at most one of them can
match the binding.

The binding text is also self-inconsistent: it says the Ethernet core
interrupt is optional while placing it first in a positional items list with
minItems: 1, which is only expressible when the optional entry is last, as
the driver assumes.

For a three-interrupt DT written from the documented order, all three values
are positive, so neither !lp->rx_irq || !lp->tx_irq nor the new < 0 tests
reject it, and axienet_init_legacy_dma() goes on to request_irq() the
Ethernet core line as a DMA handler. Should the binding or the driver be
corrected so the two agree?

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260903073252.339250-1-phucduc.bui%40gmail.com

Re: [PATCH net-next v5 3/3] net: xilinx: axienet: Fix IRQ error handling

[Bui Duc Phuc]

>
> Critical: 0 · High: 1 · Medium: 0 (1) · Low: 0
>
> - [High] Incomplete fix: the axistream-connected branch of
>   axienet_probe() still cannot request a probe retry, and this patch now…
>

irq_of_parse_and_map() has always folded every failure into plain 0,
with no way to tell "not ready yet" from "malformed DT". Before this
patch, that 0 was already turned into a terminal -ENOMEM, not
-EPROBE_DEFER, so there was no retry path to begin with - this patch
doesn't remove one, it's a pre-existing API-level limitation.

> Pre-existing issues:
> - [Medium] DT binding and driver disagree on interrupt index ordering.
>

This is a pre-existing issue, unrelated to this patch. I'll keep this
patch's scope as is.

Re: [PATCH net-next v5 3/3] net: xilinx: axienet: Fix IRQ error handling

[Simon Horman]

On Tue, Sep 08, 2026 at 09:51:26AM +0700, Bui Duc Phuc wrote:
> >
> > Critical: 0 · High: 1 · Medium: 0 (1) · Low: 0
> >
> > - [High] Incomplete fix: the axistream-connected branch of
> >   axienet_probe() still cannot request a probe retry, and this patch now…
> >
> 
> irq_of_parse_and_map() has always folded every failure into plain 0,
> with no way to tell "not ready yet" from "malformed DT". Before this
> patch, that 0 was already turned into a terminal -ENOMEM, not
> -EPROBE_DEFER, so there was no retry path to begin with - this patch
> doesn't remove one, it's a pre-existing API-level limitation.
> 
> > Pre-existing issues:
> > - [Medium] DT binding and driver disagree on interrupt index ordering.
> >
> 
> This is a pre-existing issue, unrelated to this patch. I'll keep this
> patch's scope as is.

Thanks, agreed on both counts.

Reviewed-by: Simon Horman <horms@kernel.org>