lan78xx: Failed to sync IRQ enable register: -ENODEV

lan78xx: Failed to sync IRQ enable register: -ENODEV

[Stefan Wahren]

Hi,
i noticed that recent changes to lan78xx introduced error messages to
the bootlog of Raspberry Pi 3 B Plus (arm/multi_v7_defconfig, 6.15.0-rc1).

[    8.715374] lan78xx 1-1.1.1:1.0 (unnamed net_device) (uninitialized):
No External EEPROM. Setting MAC Speed
[    9.313859] usbcore: registered new interface driver lan78xx
[   10.132752] vchiq: module is from the staging directory, the quality
is unknown, you have been warned.
[   10.533613] usbcore: registered new device driver onboard-usb-dev
[   10.533861] usb 1-1.1: USB disconnect, device number 3
[   10.533880] usb 1-1.1.1: USB disconnect, device number 6
[   10.656641] lan78xx 1-1.1.1:1.0 eth0 (unregistered): Failed to sync
IRQ enable register: -ENODEV
[   10.657440] lan78xx 1-1.1.1:1.0 eth0 (unregistered): Failed to sync
IRQ enable register: -ENODEV
[   10.658819] usb 1-1.1.2: USB disconnect, device number 5

Since this happend during only two times during boot, i added a
WARN_ON() in this specific case in order to see what's going on:

[   10.655832] ------------[ cut here ]------------
[   10.655865] WARNING: CPU: 1 PID: 161 at
drivers/net/usb/lan78xx.c:2442 lan78xx_irq_bus_sync_unlock+0x94/0xb0
[lan78xx]
[   10.655903] Modules linked in: soundcore onboard_usb_dev(+) drm_exec
ecdh_generic drm_dma_helper ecc raspberrypi_hwmon libaes bcm2835_thermal
vchiq(C) microchip lan78xx
[   10.655966] CPU: 1 UID: 0 PID: 161 Comm: systemd-udevd Tainted:
G         C          6.15.0-rc1-00002-g5f5bffb44607-dirty #431 NONE
[   10.655976] Tainted: [C]=CRAP
[   10.655980] Hardware name: BCM2835
[   10.655984] Call trace:
[   10.655999]  unwind_backtrace from show_stack+0x10/0x14
[   10.656027]  show_stack from dump_stack_lvl+0x50/0x64
[   10.656043]  dump_stack_lvl from __warn+0x80/0x128
[   10.656062]  __warn from warn_slowpath_fmt+0x170/0x178
[   10.656076]  warn_slowpath_fmt from
lan78xx_irq_bus_sync_unlock+0x94/0xb0 [lan78xx]
[   10.656092]  lan78xx_irq_bus_sync_unlock [lan78xx] from
free_irq+0x308/0x318
[   10.656110]  free_irq from phy_disconnect+0x2c/0x48
[   10.656131]  phy_disconnect from lan78xx_disconnect+0x80/0x14c [lan78xx]
[   10.656143]  lan78xx_disconnect [lan78xx] from
usb_unbind_interface+0x7c/0x290
[   10.656161]  usb_unbind_interface from
device_release_driver_internal+0x180/0x1f4
[   10.656177]  device_release_driver_internal from
bus_remove_device+0xc0/0xe4
[   10.656193]  bus_remove_device from device_del+0x138/0x424
[   10.656209]  device_del from usb_disable_device+0xc4/0x170
[   10.656223]  usb_disable_device from usb_disconnect+0xdc/0x270
[   10.656238]  usb_disconnect from usb_disconnect+0xa8/0x270
[   10.656252]  usb_disconnect from hub_quiesce+0x68/0xb4
[   10.656268]  hub_quiesce from hub_disconnect+0x38/0x164
[   10.656284]  hub_disconnect from usb_unbind_interface+0x7c/0x290
[   10.656298]  usb_unbind_interface from
device_release_driver_internal+0x180/0x1f4
[   10.656309]  device_release_driver_internal from
bus_remove_device+0xc0/0xe4
[   10.656320]  bus_remove_device from device_del+0x138/0x424
[   10.656333]  device_del from usb_disable_device+0xc4/0x170
[   10.656345]  usb_disable_device from usb_set_configuration+0x504/0x8e0
[   10.656358]  usb_set_configuration from usb_unbind_device+0x24/0x7c
[   10.656371]  usb_unbind_device from
device_release_driver_internal+0x180/0x1f4
[   10.656380]  device_release_driver_internal from device_reprobe+0x18/0x90
[   10.656391]  device_reprobe from __usb_bus_reprobe_drivers+0x40/0x6c
[   10.656407]  __usb_bus_reprobe_drivers from bus_for_each_dev+0x6c/0xb4
[   10.656421]  bus_for_each_dev from usb_register_device_driver+0x94/0xc8
[   10.656434]  usb_register_device_driver from
onboard_dev_init+0x14/0x1000 [onboard_usb_dev]
[   10.656460]  onboard_dev_init [onboard_usb_dev] from
do_one_initcall+0x40/0x1e0
[   10.656480]  do_one_initcall from do_init_module+0x50/0x1fc
[   10.656497]  do_init_module from init_module_from_file+0x90/0xbc
[   10.656513]  init_module_from_file from sys_finit_module+0x194/0x2b0
[   10.656528]  sys_finit_module from __sys_trace_return+0x0/0x10
[   10.656542] Exception stack(0xf1bf9fa8 to 0xf1bf9ff0)
[   10.656550] 9fa0:                   b6f5bf04 00000040 00000006
b6f5ad00 00000000 b6f5ba78
[   10.656556] 9fc0: b6f5bf04 00000040 6ebbc400 0000017b 006dac18
005a196b 005a19dc 006dbae0
[   10.656562] 9fe0: bee066c8 bee066b8 b6f52bc8 b6dfc580
[   10.656581] ---[ end trace 0000000000000000 ]---

Maybe some has any idea, how to fix this properly.

Best regards

Re: lan78xx: Failed to sync IRQ enable register: -ENODEV

[Oleksij Rempel]

Hi Stefan,

On Sun, Apr 13, 2025 at 09:49:00PM +0200, Stefan Wahren wrote:
> Hi,
> i noticed that recent changes to lan78xx introduced error messages to
> the bootlog of Raspberry Pi 3 B Plus (arm/multi_v7_defconfig, 6.15.0-rc1).
> 
> [    8.715374] lan78xx 1-1.1.1:1.0 (unnamed net_device) (uninitialized):
> No External EEPROM. Setting MAC Speed
> [    9.313859] usbcore: registered new interface driver lan78xx
> [   10.132752] vchiq: module is from the staging directory, the quality
> is unknown, you have been warned.
> [   10.533613] usbcore: registered new device driver onboard-usb-dev
> [   10.533861] usb 1-1.1: USB disconnect, device number 3
> [   10.533880] usb 1-1.1.1: USB disconnect, device number 6
> [   10.656641] lan78xx 1-1.1.1:1.0 eth0 (unregistered): Failed to sync
> IRQ enable register: -ENODEV
> [   10.657440] lan78xx 1-1.1.1:1.0 eth0 (unregistered): Failed to sync
> IRQ enable register: -ENODEV
> [   10.658819] usb 1-1.1.2: USB disconnect, device number 5
> 
> Since this happend during only two times during boot, i added a
> WARN_ON() in this specific case in order to see what's going on:
...
> [   10.656092]  lan78xx_irq_bus_sync_unlock from  free_irq
> [   10.656110]  free_irq from phy_disconnect
> [   10.656131]  phy_disconnect from lan78xx_disconnect
> [   10.656143]  lan78xx_disconnect from usb_unbind_interface
...
> Maybe some has any idea, how to fix this properly.

Thanks for the detailed report and backtrace!

The warning you're seeing was introduced by this patch:
0da202e6a56f ("net: usb: lan78xx: Add error handling to lan78xx_irq_bus_sync_unlock")

It adds error handling to lan78xx_irq_bus_sync_unlock() to log failed
register access.

In your case, everything in the stack is actually doing what it's
supposed to:
- lan78xx_disconnect() notifies the PHY subsystem.
- PHY framework sees the attached IRQ and calls free_irq().
- free_irq() calls irq_chip_bus_sync_unlock() ->
  lan78xx_irq_bus_sync_unlock(), where we hit the -ENODEV because
  the USB device is already gone.

The issue is that the IRQ subsystem doesn’t currently support
hot-unpluggable IRQ controllers, so there's no mechanism to tell it
"the hardware is already gone, just clean up the software state."
Until such a mechanism exists, these benign warnings can show up in
valid disconnect paths.

I can imagine a few possible options:

- Silently ignore -ENODEV in irq_bus_sync_unlock() and similar paths  
  Pro: trivial to implement  
  Contra: completely hides real issues if they happen for other reasons

- Add a global flag to suppress lan78xxx errors in .disconnect path  
  Pro: simple and less intrusive  
  Contra: same as above — poor diagnostics

- Introduce irq_domain_mark_hardware_removed() and check it in relevant paths  
  Pro: makes the real hardware state explicit, allows IRQ framework to make
       better decisions, improves diagnostics  
  Contra: requires some non-trivial changes across IRQ and driver code

Personally, I’d prefer the last option. It's harder to implement, but it gives
us the right model for handling hot-unpluggable IRQ controllers in the long
term.

All of these changes are more or less cosmetic. So far, there is no real
problem — just the fact that software is attempting to access hardware that is
already gone.  My proposal would primarily make the disconnection path cleaner
and less noisy.

It won’t prevent other parts of the driver or subsystem from hitting -ENODEV
before we reach the disconnect path. So until the driver itself is aware that
the hardware is gone and begins cleanup, we may still get register access
errors from other paths. This is expected.

Best regards,  
Oleksij Rempel
-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: lan78xx: Failed to sync IRQ enable register: -ENODEV

[Heiner Kallweit]

On 14.04.2025 07:47, Oleksij Rempel wrote:
> Hi Stefan,
> 
> On Sun, Apr 13, 2025 at 09:49:00PM +0200, Stefan Wahren wrote:
>> Hi,
>> i noticed that recent changes to lan78xx introduced error messages to
>> the bootlog of Raspberry Pi 3 B Plus (arm/multi_v7_defconfig, 6.15.0-rc1).
>>
>> [    8.715374] lan78xx 1-1.1.1:1.0 (unnamed net_device) (uninitialized):
>> No External EEPROM. Setting MAC Speed
>> [    9.313859] usbcore: registered new interface driver lan78xx
>> [   10.132752] vchiq: module is from the staging directory, the quality
>> is unknown, you have been warned.
>> [   10.533613] usbcore: registered new device driver onboard-usb-dev
>> [   10.533861] usb 1-1.1: USB disconnect, device number 3
>> [   10.533880] usb 1-1.1.1: USB disconnect, device number 6
>> [   10.656641] lan78xx 1-1.1.1:1.0 eth0 (unregistered): Failed to sync
>> IRQ enable register: -ENODEV
>> [   10.657440] lan78xx 1-1.1.1:1.0 eth0 (unregistered): Failed to sync
>> IRQ enable register: -ENODEV
>> [   10.658819] usb 1-1.1.2: USB disconnect, device number 5
>>
>> Since this happend during only two times during boot, i added a
>> WARN_ON() in this specific case in order to see what's going on:
> ...
>> [   10.656092]  lan78xx_irq_bus_sync_unlock from  free_irq
>> [   10.656110]  free_irq from phy_disconnect
>> [   10.656131]  phy_disconnect from lan78xx_disconnect
>> [   10.656143]  lan78xx_disconnect from usb_unbind_interface
> ...
>> Maybe some has any idea, how to fix this properly.
> 
> Thanks for the detailed report and backtrace!
> 
> The warning you're seeing was introduced by this patch:
> 0da202e6a56f ("net: usb: lan78xx: Add error handling to lan78xx_irq_bus_sync_unlock")
> 
> It adds error handling to lan78xx_irq_bus_sync_unlock() to log failed
> register access.
> 
> In your case, everything in the stack is actually doing what it's
> supposed to:
> - lan78xx_disconnect() notifies the PHY subsystem.
> - PHY framework sees the attached IRQ and calls free_irq().
> - free_irq() calls irq_chip_bus_sync_unlock() ->
>   lan78xx_irq_bus_sync_unlock(), where we hit the -ENODEV because
>   the USB device is already gone.
> 
> The issue is that the IRQ subsystem doesn’t currently support
> hot-unpluggable IRQ controllers, so there's no mechanism to tell it
> "the hardware is already gone, just clean up the software state."
> Until such a mechanism exists, these benign warnings can show up in
> valid disconnect paths.
> 
> I can imagine a few possible options:
> 
> - Silently ignore -ENODEV in irq_bus_sync_unlock() and similar paths  
>   Pro: trivial to implement  
>   Contra: completely hides real issues if they happen for other reasons
> 
> - Add a global flag to suppress lan78xxx errors in .disconnect path  
>   Pro: simple and less intrusive  
>   Contra: same as above — poor diagnostics
> 
> - Introduce irq_domain_mark_hardware_removed() and check it in relevant paths  
>   Pro: makes the real hardware state explicit, allows IRQ framework to make
>        better decisions, improves diagnostics  
>   Contra: requires some non-trivial changes across IRQ and driver code
> 
> Personally, I’d prefer the last option. It's harder to implement, but it gives
> us the right model for handling hot-unpluggable IRQ controllers in the long
> term.
> 
> All of these changes are more or less cosmetic. So far, there is no real
> problem — just the fact that software is attempting to access hardware that is
> already gone.  My proposal would primarily make the disconnection path cleaner
> and less noisy.
> 
> It won’t prevent other parts of the driver or subsystem from hitting -ENODEV
> before we reach the disconnect path. So until the driver itself is aware that
> the hardware is gone and begins cleanup, we may still get register access
> errors from other paths. This is expected.
> 
> Best regards,  
> Oleksij Rempel

+Thomas for the core IRQ part