[PATCH v2 1/2] net: xilinx: axienet: Propagate errors from optional IRQ lookup

[PATCH v2 1/2] 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.

Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---
 drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
index fcf517069d16..d23e9796725d 100644
--- a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
+++ b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
@@ -2957,12 +2957,16 @@ static int axienet_probe(struct platform_device *pdev)
 			lp->tx_irq = irq_of_parse_and_map(np, 0);
 			of_node_put(np);
 			lp->eth_irq = platform_get_irq_optional(pdev, 0);
+			if (lp->eth_irq < 0 && lp->eth_irq != -ENXIO)
+				return lp->eth_irq;
 		} else {
 			/* Check for these resources directly on the Ethernet node. */
 			lp->dma_regs = devm_platform_get_and_ioremap_resource(pdev, 1, NULL);
 			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);
+			if (lp->eth_irq < 0 && lp->eth_irq != -ENXIO)
+				return lp->eth_irq;
 		}
 		if (IS_ERR(lp->dma_regs)) {
 			dev_err(&pdev->dev, "could not map DMA regs\n");
-- 
2.43.0

[PATCH v2 2/2] 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.

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 d23e9796725d..7ef099db1bcf 100644
--- a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
+++ b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
@@ -3051,7 +3051,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 v2 1/2] net: xilinx: axienet: Propagate errors from optional IRQ lookup

[Simon Horman]

On Thu, Aug 13, 2026 at 11:20:11AM +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.

It would be useful to explain how this problem was discovered,
and what testing the patch has seen. Please add an Assisted-by
tag if appropriate.

Link: https://docs.kernel.org/process/coding-assistants.html

> 
> Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
> ---
>  drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> index fcf517069d16..d23e9796725d 100644
> --- a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> +++ b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> @@ -2957,12 +2957,16 @@ static int axienet_probe(struct platform_device *pdev)
>  			lp->tx_irq = irq_of_parse_and_map(np, 0);
>  			of_node_put(np);
>  			lp->eth_irq = platform_get_irq_optional(pdev, 0);
> +			if (lp->eth_irq < 0 && lp->eth_irq != -ENXIO)
> +				return lp->eth_irq;
>  		} else {
>  			/* Check for these resources directly on the Ethernet node. */
>  			lp->dma_regs = devm_platform_get_and_ioremap_resource(pdev, 1, NULL);
>  			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);
> +			if (lp->eth_irq < 0 && lp->eth_irq != -ENXIO)
> +				return lp->eth_irq;
>  		}

The same check seems to have been added to both arms of the if/else
condition. So it seems to me that it could be moved out of that condition.

I would suggest placing it below the existing rx_irq/tx_irq condition
which appears a few lines below this hunk so that those and
dma_regs errors are still propagated.

>  		if (IS_ERR(lp->dma_regs)) {
>  			dev_err(&pdev->dev, "could not map DMA regs\n");
> -- 
> 2.43.0
> 

Re: [PATCH v2 1/2] net: xilinx: axienet: Propagate errors from optional IRQ lookup

[Bui Duc Phuc]

Hi Simon,

Thank you for you review

>
> It would be useful to explain how this problem was discovered,
> and what testing the patch has seen. Please add an Assisted-by
> tag if appropriate.
>
> Link: https://docs.kernel.org/process/coding-assistants.html
>

Greg Kroah-Hartman previously asked about how this issue was discovered
and how the patch was tested, and I provided the details here:

https://lore.kernel.org/all/CAABR9nEfPqXAt8wDo597qDS3b3KMaHeF6-swAFg9RLanapDnBQ@mail.gmail.com/

Regarding AI assistance, I addressed the same question from another
maintainer here:

https://lore.kernel.org/all/CAABR9nFgiNv6cnYa3+ZY3KnjbKpcF-JHpZY8TVcR7H40vOoR=Q@mail.gmail.com/

The answers are the same in both cases, so I hope it is okay to refer
to those replies
rather than repeating the same information here.

>
> The same check seems to have been added to both arms of the if/else
> condition. So it seems to me that it could be moved out of that condition.
>
> I would suggest placing it below the existing rx_irq/tx_irq condition
> which appears a few lines below this hunk so that those and
> dma_regs errors are still propagated.
>

Previously, I understood that errors should be returned as early as possible.
However, with the current implementation, I agree that your approach
makes more sense.
I’ll send v3 soon.

Best regards,
Phuc

Re: [PATCH v2 1/2] net: xilinx: axienet: Propagate errors from optional IRQ lookup

[Simon Horman]

On Sat, Aug 15, 2026 at 10:13:59AM +0700, Bui Duc Phuc wrote:
> Hi Simon,
> 
> Thank you for you review
> 
> >
> > It would be useful to explain how this problem was discovered,
> > and what testing the patch has seen. Please add an Assisted-by
> > tag if appropriate.
> >
> > Link: https://docs.kernel.org/process/coding-assistants.html
> >
> 
> Greg Kroah-Hartman previously asked about how this issue was discovered
> and how the patch was tested, and I provided the details here:
> 
> https://lore.kernel.org/all/CAABR9nEfPqXAt8wDo597qDS3b3KMaHeF6-swAFg9RLanapDnBQ@mail.gmail.com/
> 
> Regarding AI assistance, I addressed the same question from another
> maintainer here:
> 
> https://lore.kernel.org/all/CAABR9nFgiNv6cnYa3+ZY3KnjbKpcF-JHpZY8TVcR7H40vOoR=Q@mail.gmail.com/
> 
> The answers are the same in both cases, so I hope it is okay to refer
> to those replies
> rather than repeating the same information here.

Thanks for the clarification.

For future reference, I would suggest including something
like this in the patch description.

  Found by manual code inspection.

Others may differ, but I would find that helpful.

> 
> >
> > The same check seems to have been added to both arms of the if/else
> > condition. So it seems to me that it could be moved out of that condition.
> >
> > I would suggest placing it below the existing rx_irq/tx_irq condition
> > which appears a few lines below this hunk so that those and
> > dma_regs errors are still propagated.
> >
> 
> Previously, I understood that errors should be returned as early as possible.
> However, with the current implementation, I agree that your approach
> makes more sense.

Thanks. I agree that early error detection is the norm.
But as you note, the existing structure is a bit different here.

> I’ll send v3 soon.
> 
> Best regards,
> Phuc

Re: [PATCH v2 1/2] net: xilinx: axienet: Propagate errors from optional IRQ lookup

[Bui Duc Phuc]

Hi Simon,

Thanks for the suggestion.

>
> For future reference, I would suggest including something
> like this in the patch description.
>
>   Found by manual code inspection.
>
> Others may differ, but I would find that helpful.
>

I'll include this information in future patch descriptions.

Best regards,
Phuc