drivers/net/ethernet/broadcom/asp2/bcmasp.c | 17 +++++++++-------- drivers/net/ethernet/broadcom/bcmsysport.c | 12 ++++++++++-- drivers/net/ethernet/broadcom/genet/bcmgenet.c | 8 +++++--- 3 files changed, 24 insertions(+), 13 deletions(-)
From: bui duc phuc <phucduc.bui@gmail.com> Hi all, This series improves IRQ error handling in several Broadcom Ethernet drivers by propagating IRQ lookup and request errors instead of silently ignoring them. The changes were found by manual code inspection and compile-tested only. Best regards, Phuc bui duc phuc (4): net: bcmasp: Use platform_get_irq() for IRQ lookup net: bcmasp: Propagate WoL IRQ errors from probe net: systemport: Propagate IRQ lookup errors net: bcmgenet: Propagate WoL IRQ errors drivers/net/ethernet/broadcom/asp2/bcmasp.c | 17 +++++++++-------- drivers/net/ethernet/broadcom/bcmsysport.c | 12 ++++++++++-- drivers/net/ethernet/broadcom/genet/bcmgenet.c | 8 +++++--- 3 files changed, 24 insertions(+), 13 deletions(-) -- 2.43.0
On 8/20/26 1:14 PM, phucduc.bui@gmail.com wrote: > From: bui duc phuc <phucduc.bui@gmail.com> > > Hi all, > > This series improves IRQ error handling in several Broadcom Ethernet > drivers by propagating IRQ lookup and request errors instead of > silently ignoring them. > > The changes were found by manual code inspection and compile-tested > only. ## Form letter - net-next-closed We have already submitted our pull request with net-next material for v7.3, and therefore net-next is closed for new drivers, features, code refactoring and optimizations. We are currently accepting bug fixes only. Please repost when net-next reopens after Aug 31st. RFC patches sent for review only are obviously welcome at any time. See: https://www.kernel.org/doc/html/next/process/maintainer-netdev.html#development-cycle
Hi Paolo, > ## Form letter - net-next-closed > > We have already submitted our pull request with net-next material for v7.3, > and therefore net-next is closed for new drivers, features, code refactoring > and optimizations. We are currently accepting bug fixes only. > > Please repost when net-next reopens after Aug 31st. > > RFC patches sent for review only are obviously welcome at any time. > > See: https://www.kernel.org/doc/html/next/process/maintainer-netdev.html#development-cycle > Thanks for clarifying this. I wasn't aware of this process and only knew that patches could be sent for review. I may send the patches as RFCs for now, in line with the guidelines. Best regards, Phuc
On 8/20/26 06:30, Paolo Abeni wrote: > On 8/20/26 1:14 PM, phucduc.bui@gmail.com wrote: >> From: bui duc phuc <phucduc.bui@gmail.com> >> >> Hi all, >> >> This series improves IRQ error handling in several Broadcom Ethernet >> drivers by propagating IRQ lookup and request errors instead of >> silently ignoring them. >> >> The changes were found by manual code inspection and compile-tested >> only. > ## Form letter - net-next-closed > > We have already submitted our pull request with net-next material for v7.3, > and therefore net-next is closed for new drivers, features, code refactoring > and optimizations. We are currently accepting bug fixes only. > > Please repost when net-next reopens after Aug 31st. > > RFC patches sent for review only are obviously welcome at any time. > > See: https://www.kernel.org/doc/html/next/process/maintainer-netdev.html#development-cycle > Not seeing much value in these patches, to be honest. -- Florian
On 8/20/26 9:45 AM, Florian Fainelli wrote: > On 8/20/26 06:30, Paolo Abeni wrote: >> On 8/20/26 1:14 PM, phucduc.bui@gmail.com wrote: >>> From: bui duc phuc <phucduc.bui@gmail.com> >>> >>> Hi all, >>> >>> This series improves IRQ error handling in several Broadcom Ethernet >>> drivers by propagating IRQ lookup and request errors instead of >>> silently ignoring them. >>> >>> The changes were found by manual code inspection and compile-tested >>> only. >> ## Form letter - net-next-closed >> >> We have already submitted our pull request with net-next material for >> v7.3, >> and therefore net-next is closed for new drivers, features, code >> refactoring >> and optimizations. We are currently accepting bug fixes only. >> >> Please repost when net-next reopens after Aug 31st. >> >> RFC patches sent for review only are obviously welcome at any time. >> >> See: https://www.kernel.org/doc/html/next/process/maintainer- >> netdev.html#development-cycle >> > > Not seeing much value in these patches, to be honest. Agreed. I prefer the current behavior. Even if the optional WoL IRQ exist, but fails to initialize correctly, the rest of the network functions will still work. No need to take down everything in this case. Thanks, Justin
Hi Florian, Chen, Thank you for your feedback. > > > > Not seeing much value in these patches, to be honest. > I was looking at how platform_get_irq_optional() is handled in other network drivers, such as the Xilinx and TI drivers: Xilinx : https://elixir.bootlin.com/linux/v7.2/source/drivers/net/ethernet/xilinx/xilinx_axienet_main.c#L3020 TI : https://elixir.bootlin.com/linux/v7.2/source/drivers/net/ethernet/ti/davinci_emac.c#L1444 Both drivers explicitly handle errors returned by platform_get_irq_optional() rather than treating every negative value as "no IRQ". I wonder if they handled it this way because their hardware and software are already solid. I used these implementations as references when considering the error handling in these patches. > Agreed. I prefer the current behavior. Even if the optional WoL IRQ > exist, but fails to initialize correctly, the rest of the network > functions will still work. No need to take down everything in this case. > What about -EPROBE_DEFER? Do you also want to ignore it and not give the driver a chance to probe again? Best regards, Phuc
> What about -EPROBE_DEFER? Do you also want to ignore it and not
> give the driver a chance to probe again?
Please do some git research. How long has the code been this way?
If -EPROBE_DEFER was a problem, why has nobody reported it?
Andrew
Hi Andrew,
Thank you for your feedback.
>
> > What about -EPROBE_DEFER? Do you also want to ignore it and not
> > give the driver a chance to probe again?
>
> Please do some git research. How long has the code been this way?
>
> If -EPROBE_DEFER was a problem, why has nobody reported it?
>
I did some git research as suggested and found commit 6b77c06655b8
("net: bcmgenet: Check for Wake-on-LAN interrupt probe deferral") written
by Florian back in 2022:
https://lore.kernel.org/r/20220511031752.2245566-1-f.fainelli@gmail.com
In that commit, Florian specifically highlighted that the interrupt
controller (irq-bcm7038-l1.c) might be probed after the Ethernet driver,
requiring an explicit check for -EPROBE_DEFER to ensure the interrupt is
eventually fetched.
This commit clearly shows that probe deferral and IRQ lookup issues on these
Broadcom controllers are real-world problems rather than theoretical edge cases.
Best regards,
Phuc
© 2016 - 2026 Red Hat, Inc.