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

[PATCH net-next v6 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/
Link v5 :
https://lore.kernel.org/all/20260903073252.339250-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.
Changes in v6 : 
 - Add Simon's Reviewed-by: tag.
 - Drop the Fixes: tag as this patch is intended for net-next.

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

Reviewed-by: Simon Horman <horms@kernel.org>
Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---

Changes in v6 : 
 - Add Simon's Reviewed-by: tag.
 - Drop the Fixes: tag as this patch is intended for net-next.

 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

[PATCH net-next v6 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.

Reviewed-by: Simon Horman <horms@kernel.org>
Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---

Changes in v6 : 
 - Add Simon's Reviewed-by: tag.
 - Drop the Fixes: tag as this patch is intended for net-next.

 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

[PATCH net-next v6 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.

Reviewed-by: Simon Horman <horms@kernel.org>
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.
Changes in v6 : 
 - Add Simon's Reviewed-by: tag.
 - Drop the Fixes: tag as this patch is intended for net-next.

 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 v6 3/3] net: xilinx: axienet: Fix IRQ error handling

[Gupta, Suraj]

On 9/9/2026 10:24 AM, phucduc.bui@gmail.com wrote:
> 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.
> 
> Reviewed-by: Simon Horman <horms@kernel.org>
> Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
> ---

Reviewed-by: Suraj Gupta <suraj.gupta2@amd.com>

Thanks!
Suraj

> 
> 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.
> Changes in v6 :
>   - Add Simon's Reviewed-by: tag.
>   - Drop the Fixes: tag as this patch is intended for net-next.
> 
>   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;
>   

Re: [PATCH net-next v6 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: 0 · Medium: 1 (2) · Low: 0

- [Medium] Understated impact / missing Fixes: tag.

Pre-existing issues:
- [Medium] DT binding and driver disagree on the ethernet-node
  `interrupts` list.
- [Medium] IRQ mapping leaked on probe error paths.

--

net: xilinx: axienet: Fix IRQ error handling

The probe path in axienet_probe() gets its DMA interrupts either from
irq_of_parse_and_map(), which returns 0 on failure, or from
platform_get_irq(), which returns a negative errno. The patch splits the
old combined "<= 0" test so that a zero mapping returns -EINVAL and a
negative platform_get_irq() result is propagated unchanged.

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

[Severity: Medium]
Is the commit message understating what these two new checks change?

In the branch without "axistream-connected", the interrupts come from:

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

and platform_get_irq() -> platform_get_irq_optional() -> __platform_get_irq()
-> of_irq_get() returns -EPROBE_DEFER when irq_find_host() finds no domain
for the parsed interrupt parent. The code being removed turned that into
-ENOMEM:

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

The driver core does not retry probing on -ENOMEM, so an axienet instance
whose interrupt controller is registered after the ethernet device never
appears at all. With the new "lp->rx_irq < 0" / "lp->tx_irq < 0" returns,
the deferred probe request reaches the driver core again.

The commit message describes this only as "propagate the original error code
returned by platform_get_irq() instead of returning -ENOMEM", and the
changelog says "Drop the Fixes: tag as this patch is intended for net-next".
Could the message mention the restored deferred probe behaviour, and would a
Fixes: tag be appropriate given that behaviour change?

[Severity: Medium]
This isn't a bug introduced by this patch, but the block being reworked here
enforces an interrupt ordering that disagrees with the binding.

Documentation/devicetree/bindings/net/xlnx,axi-ethernet.yaml documents:

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

while the no-"axistream-connected" 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);

that is, index 0 as Tx DMA, index 1 as Rx DMA and index 2 as the Ethernet
core interrupt.

For a device tree written to the documented order, does this put the Ethernet
core interrupt into tx_irq and the Tx DMA interrupt into rx_irq while probe
still succeeds? And does a binding-legal single-entry interrupts list get
rejected by exactly this block, now with -EINVAL or a propagated
platform_get_irq() error?

Which of the two is correct, the binding or the driver?

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

[Severity: Medium]
This is a pre-existing issue, but does this error path leak the virq mapping
created by irq_of_parse_and_map()?

The "axistream-connected" branch does:

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

and irq_dispose_mapping() does not appear anywhere in
drivers/net/ethernet/xilinx/xilinx_axienet_main.c, including in
axienet_remove().

So if rx_irq maps successfully and tx_irq comes back as 0, the new

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

returns with the rx_irq mapping still in place. The same applies to the later
returns in this branch, for example the platform_get_irq_optional() error, the
__axienet_device_reset() failure and dma_set_mask_and_coherent(). The old
-ENOMEM return had the same problem, so this isn't a new leak, but should the
mapping be disposed on these paths?

[ ... ]

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

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

[Bui Duc Phuc]

>
> Critical: 0 · High: 0 · Medium: 1 (2) · Low: 0
>
> - [Medium] Understated impact / missing Fixes: tag.
>

I've seen different opinions regarding the use of Fixes: tags in some
of my patches,
so I left the tag out to avoid unnecessary discussion.
In fact, some of my other patches did not have a Fixes: tag but were
still picked up for stable later.

So I think this is ultimately up to the maintainer's assessment.

> Pre-existing issues:
> - [Medium] DT binding and driver disagree on the ethernet-node
>   `interrupts` list.
> - [Medium] IRQ mapping leaked on probe error paths.
>

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