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@xxxxxxxxxxxxxx/
> 
> Regarding AI assistance, I addressed the same question from another
> maintainer here:
> 
> https://lore.kernel.org/all/CAABR9nFgiNv6cnYa3+ZY3KnjbKpcF-JHpZY8TVcR7H40vOoR=Q@xxxxxxxxxxxxxx/
> 
> 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