assert in phylink.c with lan7801 and dp83tc811 since kernel 6.18

assert in phylink.c with lan7801 and dp83tc811 since kernel 6.18

[Sven Schuchmann]

Hello,
I have a raspberrypi and switched from kernel 6.12 to 6.18 and now I have a crash in phylink.c.

I am using a MAC:lan7801 and PHY:dp83tc811 and now it crashes like this:

[    3.019174] usb 1-1.3: New USB device found, idVendor=0424, idProduct=7801, bcdDevice= 3.00
[    3.021152] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[    3.023192] usb 1-1.3: Product: LAN7801
[    3.025019] usb 1-1.3: Manufacturer: Microchip
[    3.026772] usb 1-1.3: SerialNumber: 00800F780100
[    3.078542] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): int urb period 64
[    3.091434] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): validation of rgmii-id with support 0000000,00000000,00000000,00006280 and advertis                                      ement 0000000,00000000,00000000,00006280 failed: -EINVAL
[    3.098928] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): can't attach PHY to usb-001:004, error -EINVAL
[    3.101094] ------------[ cut here ]------------
[    3.103163] RTNL: assertion failed at drivers/net/phy/phylink.c (2337)
[    3.105386] WARNING: CPU: 2 PID: 28 at drivers/net/phy/phylink.c:2337 phylink_disconnect_phy+0xf0/0x100
[    3.297049] Modules linked in: ipv6 libsha1
[    3.302904] CPU: 2 UID: 0 PID: 28 Comm: kworker/2:0 Not tainted 6.18.26 #2 PREEMPT
[    3.313657] Hardware name: Raspberry Pi Compute Module 4 Rev 1.1 (DT)
[    3.321854] Workqueue: usb_hub_wq hub_event
[    3.327898] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[    3.336686] pc : phylink_disconnect_phy+0xf0/0x100
[    3.343391] lr : phylink_disconnect_phy+0xf0/0x100
[    3.350035] sp : ffffffc08011b500
[    3.355285] x29: ffffffc08011b500 x28: ffffff8043918a00 x27: ffffff8043918aa0
[    3.364170] x26: ffffffd86a3ee000 x25: ffffff8043918a40 x24: 0000000000000000
[    3.373083] x23: 0000000000000010 x22: ffffff80448f6000 x21: 00000000ffffffea
[    3.382070] x20: ffffff80448f5800 x19: ffffff8041e09600 x18: 0000000000000006
[    3.390835] x17: 74612074276e6163 x16: 203a2964657a696c x15: ffffffc08011af10
[    3.399551] x14: 0000000000000000 x13: ffffff8040868540 x12: ffffffc08011afe8
[    3.407285] x11: 0000000000001e00 x10: ffffffd86a1aecf8 x9 : ffffffd868935570
[    3.415974] x8 : 00000000ffffefff x7 : ffffffd86a1aecf8 x6 : 80000000fffff000
[    3.424655] x5 : 000000000000013c x4 : 0000000000000000 x3 : 0000000000000000
[    3.433329] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffff8040838000
[    3.441991] Call trace:
[    3.445951]  phylink_disconnect_phy+0xf0/0x100 (P)
[    3.452249]  lan78xx_probe+0xbcc/0xe18
[    3.457460]  usb_probe_interface+0xd8/0x2b8
[    3.463100]  really_probe+0xc4/0x2b0
[    3.468141]  __driver_probe_device+0x80/0x140
[    3.473945]  driver_probe_device+0xe0/0x170
[    3.479559]  __device_attach_driver+0xc0/0x148
[    3.485426]  bus_for_each_drv+0x90/0xf8
[    3.490669]  __device_attach+0xa8/0x1a0
[    3.495914]  device_initial_probe+0x1c/0x30
[    3.501476]  bus_probe_device+0xb4/0xc0
[    3.506658]  device_add+0x588/0x768
[    3.511470]  usb_set_configuration+0x4b4/0xaa0
[    3.517231]  usb_generic_driver_probe+0x68/0x98
[    3.523074]  usb_probe_device+0x44/0x128
[    3.528243]  really_probe+0xc4/0x2b0
[    3.533015]  __driver_probe_device+0x80/0x140
[    3.538536]  driver_probe_device+0xe0/0x170
[    3.543874]  __device_attach_driver+0xc0/0x148
[    3.549475]  bus_for_each_drv+0x90/0xf8
[    3.554471]  __device_attach+0xa8/0x1a0
[    3.559458]  device_initial_probe+0x1c/0x30
[    3.564768]  bus_probe_device+0xb4/0xc0
[    3.569671]  device_add+0x588/0x768
[    3.574233]  usb_new_device+0x400/0x4f0
[    3.579126]  hub_event+0xddc/0x1578
[    3.583646]  process_one_work+0x158/0x3b8
[    3.588662]  worker_thread+0x194/0x328
[    3.593398]  kthread+0x14c/0x210
[    3.597604]  ret_from_fork+0x10/0x20
[    3.602138] ---[ end trace 0000000000000000 ]---
[    3.617830] lan78xx 1-1.3:1.0: probe with driver lan78xx failed with error -22


it seems to happen over here:
/**
 * phylink_disconnect_phy() - disconnect any PHY attached to the phylink
 *   instance.
 * @pl: a pointer to a &struct phylink returned from phylink_create()
 *
 * Disconnect any current PHY from the phylink instance described by @pl.
 */
void phylink_disconnect_phy(struct phylink *pl)
{
      struct phy_device *phy;

      ASSERT_RTNL();

Maybe anyone can help me?

Regards,

   Sven

Re: assert in phylink.c with lan7801 and dp83tc811 since kernel 6.18

[Andrew Lunn]

On Tue, May 05, 2026 at 09:53:06AM +0000, Sven Schuchmann wrote:
> Hello,
> I have a raspberrypi and switched from kernel 6.12 to 6.18 and now I have a crash in phylink.c.

Please could you try 7.0.3, or better still, 7.1-rcX. We need to
determine if the problem has already been fixed and just needs
backporting, or is it a new problem.


> I am using a MAC:lan7801 and PHY:dp83tc811 and now it crashes like this:
> 
> [    3.019174] usb 1-1.3: New USB device found, idVendor=0424, idProduct=7801, bcdDevice= 3.00
> [    3.021152] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> [    3.023192] usb 1-1.3: Product: LAN7801
> [    3.025019] usb 1-1.3: Manufacturer: Microchip
> [    3.026772] usb 1-1.3: SerialNumber: 00800F780100
> [    3.078542] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): int urb period 64
> [    3.091434] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): validation of rgmii-id with support 0000000,00000000,00000000,00006280 and advertis                                      ement 0000000,00000000,00000000,00006280 failed: -EINVAL

This appears to be the real problem.

> [    3.098928] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): can't attach PHY to usb-001:004, error -EINVAL
> [    3.101094] ------------[ cut here ]------------
> [    3.103163] RTNL: assertion failed at drivers/net/phy/phylink.c (2337)

and this is a knock on problem, which normally you don't see.

Please could you make line 1 of drivers/net/phy/phylink.c.

#define DEBUG 1

That will give us additional debug info.

     Andrew

AW: assert in phylink.c with lan7801 and dp83tc811 since kernel 6.18

[Sven Schuchmann]

Hi Andrew

> Von: Andrew Lunn <andrew@lunn.ch>
>  On Tue, May 05, 2026 at 09:53:06AM +0000, Sven Schuchmann wrote:
> > Hello,
> > I have a raspberrypi and switched from kernel 6.12 to 6.18 and now I have a crash in phylink.c.
> Please could you try 7.0.3, or better still, 7.1-rcX. We need to
> determine if the problem has already been fixed and just needs
> backporting, or is it a new problem.

Now tried with: Linux rpi 7.1.0-rc2-v8+ #6 SMP PREEMPT Wed May  6 09:07:34 CEST 2026 aarch64 GNU/Linux

> Please could you make line 1 of drivers/net/phy/phylink.c.
Also done

Still crashing -> see below for more details
[    2.153568] usb 1-1.3: new high-speed USB device number 3 using dwc2
[    2.266726] usb 1-1.3: New USB device found, idVendor=0424, idProduct=7801, bcdDevice= 3.00
[    2.266762] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[    2.266772] usb 1-1.3: Product: LAN7801
[    2.266781] usb 1-1.3: Manufacturer: Microchip
[    2.266789] usb 1-1.3: SerialNumber: 00800F780100
[    2.323106] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): int urb period 64
[    2.334333] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): PHY usb-001:003:00 doesn't supply possible interfaces
[    2.334360] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): validation of rgmii-id with support 00000000,00000000,00000000,00006280 and advertisement 00000000,00000000,00000000,00006280 failed: -EINVAL
[    2.339481] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): can't attach PHY to usb-001:003, error -EINVAL
[    2.339519] ------------[ cut here ]------------
[    2.339525] RTNL: assertion failed at drivers/net/phy/phylink.c (2351)
[    2.339613] WARNING: drivers/net/phy/phylink.c:2351 at phylink_disconnect_phy+0xf0/0x100, CPU#0: kworker/0:0/9
[    2.851713] Modules linked in:
[    2.854770] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:0 Not tainted 7.1.0-rc2-v8+ #6 PREEMPT
[    2.862861] Hardware name: Raspberry Pi Compute Module 4 Rev 1.0 (DT)
[    2.869297] Workqueue: usb_hub_wq hub_event
[    2.873486] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[    2.880444] pc : phylink_disconnect_phy+0xf0/0x100
[    2.885233] lr : phylink_disconnect_phy+0xf0/0x100
[    2.890021] sp : ffffffc08006b4d0
[    2.893328] x29: ffffffc08006b4d0 x28: ffffff810703ea40 x27: ffffff81053e0000
[    2.900467] x26: ffffff810703eae0 x25: ffffff810703ea80 x24: 00000000ffffffea
[    2.907605] x23: ffffff81051ebc50 x22: ffffff81052d80b0 x21: 0000000000008000
[    2.914742] x20: ffffff810629a000 x19: ffffff8105a50600 x18: 0000000000000006
[    2.921879] x17: 74612074276e6163 x16: 203a2964657a696c x15: 077907680770072f
[    2.929016] x14: 07740765076e072f x13: 077907680770072f x12: 07740765076e072f
[    2.936152] x11: 0720072007200720 x10: 0720072007200729 x9 : ffffffe227d591ec
[    2.943289] x8 : 0000000000000128 x7 : ffffffe22941d100 x6 : ffffffe22941d100
[    2.950426] x5 : 3fffffffffffefff x4 : bffffffffffff000 x3 : 0000000000000000
[    2.957563] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffff810033de80
[    2.964701] Call trace:
[    2.967141]  phylink_disconnect_phy+0xf0/0x100 (P)
[    2.971932]  lan78xx_probe+0x9e4/0xda0
[    2.975679]  usb_probe_interface+0x13c/0x360
[    2.979946]  really_probe+0xc4/0x2d0
[    2.983521]  __driver_probe_device+0x88/0x160
[    2.987876]  driver_probe_device+0x44/0x160
[    2.992057]  __device_attach_driver+0xc0/0x150
[    2.996499]  bus_for_each_drv+0x90/0x100
[    3.000419]  __device_attach+0xa8/0x1a0
[    3.004252]  device_initial_probe+0x58/0x68
[    3.008433]  bus_probe_device+0x40/0xb0
[    3.012266]  device_add+0x5a4/0x7b8
[    3.015751]  usb_set_configuration+0x548/0xab0
[    3.020195]  usb_generic_driver_probe+0x5c/0xa0
[    3.024724]  usb_probe_device+0x44/0x140
[    3.028645]  really_probe+0xc4/0x2d0
[    3.032218]  __driver_probe_device+0x88/0x160
[    3.036573]  driver_probe_device+0x44/0x160
[    3.040754]  __device_attach_driver+0xc0/0x150
[    3.045195]  bus_for_each_drv+0x90/0x100
[    3.049114]  __device_attach+0xa8/0x1a0
[    3.052947]  device_initial_probe+0x58/0x68
[    3.057128]  bus_probe_device+0x40/0xb0
[    3.060961]  device_add+0x5a4/0x7b8
[    3.064446]  usb_new_device+0x1bc/0x4e8
[    3.068278]  hub_event+0xde8/0x1560
[    3.071763]  process_one_work+0x164/0x4e0
[    3.075774]  worker_thread+0x19c/0x320
[    3.079519]  kthread+0x138/0x150
[    3.082742]  ret_from_fork+0x10/0x20
[    3.086317] ---[ end trace 0000000000000000 ]---
[    3.113678] lan78xx 1-1.3:1.0: probe with driver lan78xx failed with error -22

due to my limited debugging skills I put my kernel over here:
https://github.com/Schuchmann/rpi_lan78xx

added some code to maybe get a better idea:
https://github.com/Schuchmann/rpi_lan78xx/pull/1/changes

[    2.117653] usb 1-1.3: new high-speed USB device number 3 using dwc2
[    2.214810] usb 1-1.3: New USB device found, idVendor=0424, idProduct=7801, bcdDevice= 3.00
[    2.214840] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[    2.214850] usb 1-1.3: Product: LAN7801
[    2.214857] usb 1-1.3: Manufacturer: Microchip
[    2.214864] usb 1-1.3: SerialNumber: 00800F780100
[    2.215258] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): --1--
[    2.215275] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): --2--
[    2.215284] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): --3--
[    2.215310] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): --4--
[    2.215334] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): --5--
[    2.215350] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): --6--
[    2.215358] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): --7--
[    2.215365] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): --8--
[    2.215373] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): --9--
[    2.215380] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): --10--
[    2.215388] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): --11--
[    2.225577] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): deferred multicast write 0x00007ca0
[    2.272191] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): registered mdiobus bus usb-001:003
[    2.272211] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): --12--
[    2.272234] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): --13--
[    2.272243] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): int urb period 64
[    2.272254] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): --14--
[    2.272263] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): --15--
[    2.272270] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): --16--
[    2.272282] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): --17--
[    2.272289] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): --18--
[    2.272300] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): phy: --3.2--
[    2.272305] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): phy: --3.3--
[    2.272312] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): phy: --3.4--
[    2.272316] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): phy: --3.5-- 0
[    2.272433] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): phydev->irq = 37
[    2.272440] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): phy: --1--
[    2.272444] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): phy: --2--
[    2.283504] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): phy: --3--
[    2.283520] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): PHY usb-001:003:00 doesn't supply possible interfaces
[    2.283528] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): PHY usb-001:003:00 --1.1--
[    2.283533] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): PHY usb-001:003:00 --1.2--
[    2.283538] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): phy: --3.2--
[    2.283542] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): phy: --3.3--
[    2.283549] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): phy: --3.4--
[    2.283553] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): phy: --3.5-- -22
[    2.283559] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): validation of rgmii-id with support 00000000,00000000,00000000,00006280 and advertisement 00000000,00000000,00000000,00006280 failed: -EINVAL
[    2.288572] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): can't attach PHY to usb-001:003, error -EINVAL
[    2.288617] ------------[ cut here ]------------
[    2.288624] RTNL: assertion failed at drivers/net/phy/phylink.c (2377)
[    2.288730] WARNING: drivers/net/phy/phylink.c:2377 at phylink_disconnect_phy+0xf0/0x100, CPU#0: kworker/0:2/68
[    2.962641] Modules linked in:
[    2.965698] CPU: 0 UID: 0 PID: 68 Comm: kworker/0:2 Not tainted 7.1.0-rc2-v8+ #12 PREEMPT
[    2.973963] Hardware name: Raspberry Pi Compute Module 4 Rev 1.0 (DT)
[    2.980399] Workqueue: usb_hub_wq hub_event
[    2.984589] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[    2.991547] pc : phylink_disconnect_phy+0xf0/0x100
[    2.996335] lr : phylink_disconnect_phy+0xf0/0x100
[    3.001122] sp : ffffffc080d034d0
[    3.004430] x29: ffffffc080d034d0 x28: ffffff8105f0ea80 x27: ffffff8105f0eb28
[    3.011568] x26: ffffff8105f0eae0 x25: ffffff810622bc50 x24: 00000000ffffffea
[    3.018705] x23: ffffff81058708b0 x22: 0000000000008000 x21: ffffff8105877000
[    3.025842] x20: ffffff8105f0ea40 x19: ffffff810027ce00 x18: 0000000000000006
[    3.032979] x17: 74612074276e6163 x16: 203a2964657a696c x15: 077907680770072f
[    3.040116] x14: 07740765076e072f x13: 077907680770072f x12: 07740765076e072f
[    3.047253] x11: 0720072007200720 x10: 0720072007200729 x9 : ffffffd85f3591ec
[    3.054390] x8 : 000000000000014a x7 : ffffffd860a1d100 x6 : ffffffd860a1d100
[    3.061527] x5 : 3fffffffffffefff x4 : bffffffffffff000 x3 : 0000000000000000
[    3.068664] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffff8102419f80
[    3.075801] Call trace:
[    3.078241]  phylink_disconnect_phy+0xf0/0x100 (P)
[    3.083031]  lan78xx_probe+0xb00/0x1208
[    3.086865]  usb_probe_interface+0x13c/0x360
[    3.091132]  really_probe+0xc4/0x2d0
[    3.094709]  __driver_probe_device+0x88/0x160
[    3.099064]  driver_probe_device+0x44/0x160
[    3.103244]  __device_attach_driver+0xc0/0x150
[    3.107686]  bus_for_each_drv+0x90/0x100
[    3.111605]  __device_attach+0xa8/0x1a0
[    3.115438]  device_initial_probe+0x58/0x68
[    3.119618]  bus_probe_device+0x40/0xb0
[    3.123451]  device_add+0x5a4/0x7b8
[    3.126935]  usb_set_configuration+0x548/0xab0
[    3.131377]  usb_generic_driver_probe+0x5c/0xa0
[    3.135907]  usb_probe_device+0x44/0x140
[    3.139827]  really_probe+0xc4/0x2d0
[    3.143399]  __driver_probe_device+0x88/0x160
[    3.147753]  driver_probe_device+0x44/0x160
[    3.151934]  __device_attach_driver+0xc0/0x150
[    3.156375]  bus_for_each_drv+0x90/0x100
[    3.160294]  __device_attach+0xa8/0x1a0
[    3.164127]  device_initial_probe+0x58/0x68
[    3.168307]  bus_probe_device+0x40/0xb0
[    3.172140]  device_add+0x5a4/0x7b8
[    3.175624]  usb_new_device+0x1bc/0x4e8
[    3.179456]  hub_event+0xde8/0x1560
[    3.182940]  process_one_work+0x164/0x4e0
[    3.186949]  worker_thread+0x19c/0x320
[    3.190694]  kthread+0x138/0x150
[    3.193917]  ret_from_fork+0x10/0x20
[    3.197495] ---[ end trace 0000000000000000 ]---
[    3.202212] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): --out: free_urbs--
[    3.202245] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): --out: out5--
[    3.202725] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): --out: out4--
[    3.225689] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): --out: out3--
[    3.225735] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): --out: out2--

So for me it somewhere happens in phylink_validate_mac_and_pcs()

Regards,

   Sven

Re: assert in phylink.c with lan7801 and dp83tc811 since kernel 6.18

[Andrew Lunn]

> So for me it somewhere happens in phylink_validate_mac_and_pcs()

I was expecting to see more debug output, but reading the code, i was
also thinking we need to look at phylink_validate_mac_and_pcs().

You are going in the correct direction putting lots of printk() in the
code. We need to find where it returns EINVAL:

static int phylink_validate_mac_and_pcs(struct phylink *pl,
					unsigned long *supported,
					struct phylink_link_state *state)
{
	struct phylink_pcs *pcs = NULL;
	unsigned long capabilities;
	int ret;

	/* Get the PCS for this interface mode */
	if (pl->mac_ops->mac_select_pcs) {
		pcs = pl->mac_ops->mac_select_pcs(pl->config, state->interface);
		if (IS_ERR(pcs))
			return PTR_ERR(pcs);
Possibly.


	}

	if (pcs) {
		/* The PCS, if present, must be setup before phylink_create()
		 * has been called. If the ops is not initialised, print an
		 * error and backtrace rather than oopsing the kernel.
		 */
		if (!pcs->ops) {
			phylink_err(pl, "interface %s: uninitialised PCS\n",
				    phy_modes(state->interface));
			dump_stack();
We don't see a stack dump, so not here.

			return -EINVAL;
		}

		/* Ensure that this PCS supports the interface which the MAC
		 * returned it for. It is an error for the MAC to return a PCS
		 * that does not support the interface mode.
		 */
		if (!phy_interface_empty(pcs->supported_interfaces) &&
		    !test_bit(state->interface, pcs->supported_interfaces)) {
			phylink_err(pl, "MAC returned PCS which does not support %s\n",
				    phy_modes(state->interface));
No error message....				    
			return -EINVAL;
		}

		/* Validate the link parameters with the PCS */
		if (pcs->ops->pcs_validate) {
			ret = pcs->ops->pcs_validate(pcs, supported, state);
			if (ret < 0 || phylink_is_empty_linkmode(supported))
Could be...			
				return -EINVAL;

			/* Ensure the advertising mask is a subset of the
			 * supported mask.
			 */
			linkmode_and(state->advertising, state->advertising,
				     supported);
		}
	}

	/* Then validate the link parameters with the MAC */
	if (pl->mac_ops->mac_get_caps)
		capabilities = pl->mac_ops->mac_get_caps(pl->config,
							 state->interface);
	else
		capabilities = pl->config->mac_capabilities;

	phylink_validate_mask_caps(supported, state, capabilities);

	return phylink_is_empty_linkmode(supported) ? -EINVAL : 0;

Also possible.

}

In the end, we are probably going to find that what the MAC says its
capabilities are don't match what the PCS says it can do.

Thinking about that, it says phy mode RGMII. You generally don't use a
PCS with RGMII, so that is suspicious.

    Andrew

Re: assert in phylink.c with lan7801 and dp83tc811 since kernel 6.18

[Maxime Chevallier]

On 06/05/2026 14:39, Andrew Lunn wrote:
>> So for me it somewhere happens in phylink_validate_mac_and_pcs()
> 
> I was expecting to see more debug output, but reading the code, i was
> also thinking we need to look at phylink_validate_mac_and_pcs().
> 
> You are going in the correct direction putting lots of printk() in the
> code. We need to find where it returns EINVAL:

[...]

> 
> In the end, we are probably going to find that what the MAC says its
> capabilities are don't match what the PCS says it can do.
> 
> Thinking about that, it says phy mode RGMII. You generally don't use a
> PCS with RGMII, so that is suspicious.
> 

Another thing to consider is that in this case, we're attaching to a
dp83tc811, so a 100BaseT1 PHY. Does the PHY driver correctly populates
the supported features ?

Could be that we're getting an empty-ish phydev->supported after reading
the abilities, as this is not a typical BaseT PHY

Maxime

Re: assert in phylink.c with lan7801 and dp83tc811 since kernel 6.18

[Andrew Lunn]

On Wed, May 06, 2026 at 03:04:42PM +0200, Maxime Chevallier wrote:
> 
> 
> On 06/05/2026 14:39, Andrew Lunn wrote:
> >> So for me it somewhere happens in phylink_validate_mac_and_pcs()
> > 
> > I was expecting to see more debug output, but reading the code, i was
> > also thinking we need to look at phylink_validate_mac_and_pcs().
> > 
> > You are going in the correct direction putting lots of printk() in the
> > code. We need to find where it returns EINVAL:
> 
> [...]
> 
> > 
> > In the end, we are probably going to find that what the MAC says its
> > capabilities are don't match what the PCS says it can do.
> > 
> > Thinking about that, it says phy mode RGMII. You generally don't use a
> > PCS with RGMII, so that is suspicious.
> > 
> 
> Another thing to consider is that in this case, we're attaching to a
> dp83tc811, so a 100BaseT1 PHY. Does the PHY driver correctly populates
> the supported features ?

Using RGMII to connect to a 100BaseT is also odd. It does happen, but
it is a bit of a corner case, and something could be going wrong here.

   Andrew

AW: assert in phylink.c with lan7801 and dp83tc811 since kernel 6.18

[Sven Schuchmann]

Hi,

> > Von: Andrew Lunn <andrew@lunn.ch>
> > Gesendet: Mittwoch, 06. Mai 2026 15:18
> > An: Maxime Chevallier <maxime.chevallier@bootlin.com>
> > Cc: Sven Schuchmann <schuchmann@schleissheimer.de>; netdev@vger.kernel.org <netdev@vger.kernel.org>
> > Betreff: Re: assert in phylink.c with lan7801 and dp83tc811 since kernel 6.18
> 
> On Wed, May 06, 2026 at 03:04:42PM +0200, Maxime Chevallier wrote:
> > On 06/05/2026 14:39, Andrew Lunn wrote:
> > >> So for me it somewhere happens in phylink_validate_mac_and_pcs()
> > > I was expecting to see more debug output, but reading the code, i was
> > > also thinking we need to look at phylink_validate_mac_and_pcs().
> > > You are going in the correct direction putting lots of printk() in the
> > > code. We need to find where it returns EINVAL:
> > [...]
> > > In the end, we are probably going to find that what the MAC says its
> 
> > > capabilities are don't match what the PCS says it can do.
> > > Thinking about that, it says phy mode RGMII. You generally don't use a
> > > PCS with RGMII, so that is suspicious.

> > Another thing to consider is that in this case, we're attaching to a
> > dp83tc811, so a 100BaseT1 PHY. Does the PHY driver correctly populates
> > the supported features ?

> Using RGMII to connect to a 100BaseT is also odd. It does happen, but
> it is a bit of a corner case, and something could be going wrong here.

What I can at least say that it was working with kernel 6.12 on 
the same hardware. But I do not know about the supported features population.

I added some debug code to the end of phylink_validate_mac_and_pcs():

	/* Then validate the link parameters with the MAC */
	if (pl->mac_ops->mac_get_caps)
		capabilities = pl->mac_ops->mac_get_caps(pl->config,
							 state->interface);
	else
		capabilities = pl->config->mac_capabilities;

	phylink_validate_mask_caps(supported, state, capabilities);

	phylink_dbg(pl, "phy: --3.4 supported    0x%x\n", supported);
	phylink_dbg(pl, "phy: --3.4 capabilities 0x%x\n", capabilities);

	int retval = phylink_is_empty_linkmode(supported) ? -EINVAL : 0;
	phylink_dbg(pl, "phy: --3.5-- %d\n", retval);
	return retval;
}

and the output I get is:
[    2.771602] lan78xx 1-1.4:1.0 (unnamed net_device) (uninitialized): phy: --3.4 supported    0x80cf3430
[    2.771607] lan78xx 1-1.4:1.0 (unnamed net_device) (uninitialized): phy: --3.4 capabilities 0xbf
[    2.771611] lan78xx 1-1.4:1.0 (unnamed net_device) (uninitialized): phy: --3.5-- -22
[    2.771616] lan78xx 1-1.4:1.0 (unnamed net_device) (uninitialized): validation of rgmii-id with support 00000000,00000000,00000000,00006280 and advertisement 00000000,00000000,00000000,00006280 failed: -EINVAL

But I do not get what phylink_is_empty_linkmode() is doing...

Regards,

   Sven

Re: assert in phylink.c with lan7801 and dp83tc811 since kernel 6.18

[Andrew Lunn]

> 	phylink_dbg(pl, "phy: --3.4 supported    0x%x\n", supported);

supported is a pointer, so you cannot get anything useful from
printing its value.

> [    2.771616] lan78xx 1-1.4:1.0 (unnamed net_device) (uninitialized): validation of rgmii-id with support 00000000,00000000,00000000,00006280 and advertisement 00000000,00000000,00000000,00006280 failed: -EINVAL
 
> But I do not get what phylink_is_empty_linkmode() is doing...

The supported value is a combination of a few things. It indicates if
the PHY supports auto negotiation, pause, asym pause, if the link is
using twisted pair, fibre etc. It also lists the speeds the PHY
supports. There is a list here:

https://elixir.bootlin.com/linux/v7.0.1/source/include/uapi/linux/ethtool.h#L1963

Decoding 00006280 we get:

ETHTOOL_LINK_MODE_TP_BIT,
ETHTOOL_LINK_MODE_MII_BIT,
ETHTOOL_LINK_MODE_Pause_BIT,
ETHTOOL_LINK_MODE_Asym_Pause_BIT

So Maxime was correct, it is not listing any link speeds. From what i
understand, it is a 100BaseT1? So you would expect to see:

ETHTOOL_LINK_MODE_100baseT1_Full_BIT

which is bit 67.

phylib asks the PHY what it can do. For BaseT1 that would be
genphy_c45_pma_baset1_read_abilities()

https://elixir.bootlin.com/linux/v7.0.1/source/drivers/net/phy/phy-c45.c#L971

either the PHY has the wrong value in its register, or the function is
not getting called.

The PHY is an dp83tc811?

https://elixir.bootlin.com/linux/v7.0.1/source/drivers/net/phy/dp83tc811.c#L387

It does not set .get_features. However, dp83tg720.c does:

https://elixir.bootlin.com/linux/v7.0.1/source/drivers/net/phy/dp83tg720.c#L654

So try adding:

	.get_features	= genphy_c45_pma_read_ext_abilities,

	Andrew

AW: assert in phylink.c with lan7801 and dp83tc811 since kernel 6.18

[Sven Schuchmann]

Hi Andew,

thanks for the detailed explanation! Indeed adding  
.get_features   = genphy_c45_pma_read_ext_abilities,
to "dp83tc811.c" makes the network work again:

[    2.253619] usb 1-1.3: new high-speed USB device number 3 using dwc2
[    2.342774] usb 1-1.3: New USB device found, idVendor=0424, idProduct=7801, bcdDevice= 3.00
[    2.342810] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[    2.342820] usb 1-1.3: Product: LAN7801
[    2.342828] usb 1-1.3: Manufacturer: Microchip
[    2.342835] usb 1-1.3: SerialNumber: 00800F780100
[    2.353766] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): deferred multicast write 0x00007ca0
[    2.466961] systemd[1]: System time advanced to timestamp on /var/lib/systemd/timesync/clock: Thu 2026-05-07 08:03:39 CEST
[    2.500632] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): registered mdiobus bus usb-001:003
[    2.500675] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): int urb period 64
[    2.500877] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): phydev->irq = 37
[    2.511949] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): PHY usb-001:003:00 doesn't supply possible interfaces
[    2.511990] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): PHY [usb-001:003:00] driver [TI DP83TC811] (irq=37)
[    2.512005] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): phy: rgmii-id setting supported 00000000,00000008,00000000,00006000 advertising 00000000,00000008,00000000,00006000
[...]
[   10.336369] lan78xx 1-1.3:1.0 broadr1: configuring for phy/rgmii-id link mode
[   10.336397] lan78xx 1-1.3:1.0 broadr1: major config, requested phy/rgmii-id
[   10.336422] lan78xx 1-1.3:1.0 broadr1: major config, active phy/none/rgmii-id
[   10.336432] lan78xx 1-1.3:1.0 broadr1: phylink_mac_config: mode=phy/rgmii-id/none adv=00000000,00000000,00000000,00000000 pause=00
[   10.337360] lan78xx 1-1.3:1.0 broadr1: PHY INTR: 0x00020000
[   10.341302] lan78xx 1-1.3:1.0 broadr1: receive multicast hash filter
[   10.341445] lan78xx 1-1.3:1.0 broadr1: receive multicast hash filter
[   10.342409] lan78xx 1-1.3:1.0 broadr1: deferred multicast write 0x00007ca2
[   10.345161] lan78xx 1-1.3:1.0 broadr1: phy link up rgmii-id/100Mbps/Full/none/off/nolpi
[   10.347681] lan78xx 1-1.3:1.0 broadr1: start tx path
[   10.348201] lan78xx 1-1.3:1.0 broadr1: start rx path
[   10.348730] lan78xx 1-1.3:1.0 broadr1: Link is Up - 100Mbps/Full - flow control off

I think it is worth doing a patch on this also?
I am not that experienced in sending kernel patches but I could try...

Regards,

    Sven


________________________________________
Von: Andrew Lunn <andrew@lunn.ch>
Gesendet: Mittwoch, 06. Mai 2026 18:40
An: Sven Schuchmann <schuchmann@schleissheimer.de>
Cc: Maxime Chevallier <maxime.chevallier@bootlin.com>; netdev@vger.kernel.org <netdev@vger.kernel.org>
Betreff: Re: assert in phylink.c with lan7801 and dp83tc811 since kernel 6.18


>        phylink_dbg(pl, "phy: --3.4 supported    0x%x\n", supported);



supported is a pointer, so you cannot get anything useful from

printing its value.



> [    2.771616] lan78xx 1-1.4:1.0 (unnamed net_device) (uninitialized): validation of rgmii-id with support 00000000,00000000,00000000,00006280 and advertisement 00000000,00000000,00000000,00006280 failed: -EINVAL

 

> But I do not get what phylink_is_empty_linkmode() is doing...



The supported value is a combination of a few things. It indicates if

the PHY supports auto negotiation, pause, asym pause, if the link is

using twisted pair, fibre etc. It also lists the speeds the PHY

supports. There is a list here:



https://elixir.bootlin.com/linux/v7.0.1/source/include/uapi/linux/ethtool.h#L1963



Decoding 00006280 we get:



ETHTOOL_LINK_MODE_TP_BIT,

ETHTOOL_LINK_MODE_MII_BIT,

ETHTOOL_LINK_MODE_Pause_BIT,

ETHTOOL_LINK_MODE_Asym_Pause_BIT



So Maxime was correct, it is not listing any link speeds. From what i

understand, it is a 100BaseT1? So you would expect to see:



ETHTOOL_LINK_MODE_100baseT1_Full_BIT



which is bit 67.



phylib asks the PHY what it can do. For BaseT1 that would be

genphy_c45_pma_baset1_read_abilities()



https://elixir.bootlin.com/linux/v7.0.1/source/drivers/net/phy/phy-c45.c#L971



either the PHY has the wrong value in its register, or the function is

not getting called.



The PHY is an dp83tc811?



https://elixir.bootlin.com/linux/v7.0.1/source/drivers/net/phy/dp83tc811.c#L387



It does not set .get_features. However, dp83tg720.c does:



https://elixir.bootlin.com/linux/v7.0.1/source/drivers/net/phy/dp83tg720.c#L654



So try adding:



        .get_features   = genphy_c45_pma_read_ext_abilities,



        Andrew

Re: assert in phylink.c with lan7801 and dp83tc811 since kernel 6.18

[Andrew Lunn]

> I think it is worth doing a patch on this also?
> I am not that experienced in sending kernel patches but I could try...

Please try, and i will help you.

A good place to start is:

https://docs.kernel.org/process/submitting-patches.html

and

https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html

	Andrew

Re: assert in phylink.c with lan7801 and dp83tc811 since kernel 6.18

[Andrew Lunn]

> [    2.339481] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): can't attach PHY to usb-001:003, error -EINVAL

static int lan78xx_phy_init(struct lan78xx_net *dev)
{
...

       ret = phylink_connect_phy(dev->phylink, phydev);
        if (ret) {
                netdev_err(dev->net, "can't attach PHY to %s, error %pe\n",
                           dev->mdiobus->id, ERR_PTR(ret));
                goto phylink_uninit;
        }

This is the error message we see.

phylink_uninit:
        lan78xx_phy_uninit(dev);

        return ret;
}

and

static void lan78xx_phy_uninit(struct lan78xx_net *dev)
{
        if (dev->phylink) {
                phylink_disconnect_phy(dev->phylink);
                phylink_destroy(dev->phylink);
                dev->phylink = NULL;
        }
}

We see the error message because phylink_connect_phy() failed. If
connect failed, you should not call disconnect.

The general pattern in Linux is that you undo what went correctly at
the end of the function.

Please try this patch.

       Andrew

From ea55645b23092a0de7aa3ab0eaf7bcb73a7fb0e1 Mon Sep 17 00:00:00 2001
From: Andrew Lunn <andrew@lunn.ch>
Date: Wed, 6 May 2026 08:10:29 -0500
Subject: [PATCH] net: usb: lan78xx: Fix cleanup in lan78xx_phy_init

If phylink_connect_phy() fails, phylink_disconnect() should not be
called. Rather than use lan78xx_phy_uninit() which does too much, add
the cleanup at the end of the function and only undo what was
successfully done.

Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
 drivers/net/usb/lan78xx.c | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c
index bcf293ea1bd3..9cfc122d76ef 100644
--- a/drivers/net/usb/lan78xx.c
+++ b/drivers/net/usb/lan78xx.c
@@ -2842,7 +2842,7 @@ static int lan78xx_phy_init(struct lan78xx_net *dev)
 
 	ret = lan78xx_mac_prepare_for_phy(dev);
 	if (ret < 0)
-		goto phylink_uninit;
+		goto destroy_phylink;
 
 	/* If no PHY is found, set up a fixed link. It is very specific to
 	 * the LAN7801 and is used in special cases like EVB-KSZ9897-1 where
@@ -2852,7 +2852,7 @@ static int lan78xx_phy_init(struct lan78xx_net *dev)
 	if (!phydev) {
 		ret = lan78xx_set_fixed_link(dev);
 		if (ret < 0)
-			goto phylink_uninit;
+			goto destroy_phylink;
 
 		/* No PHY found, so set up a fixed link and return early.
 		 * No need to configure PHY IRQ or attach to phylink.
@@ -2871,17 +2871,19 @@ static int lan78xx_phy_init(struct lan78xx_net *dev)
 	if (ret) {
 		netdev_err(dev->net, "can't attach PHY to %s, error %pe\n",
 			   dev->mdiobus->id, ERR_PTR(ret));
-		goto phylink_uninit;
+		goto destroy_phylink;
 	}
 
 	ret = lan78xx_configure_leds_from_dt(dev, phydev);
 	if (ret < 0)
-		goto phylink_uninit;
+		goto disconnect_phylink;
 
 	return 0;
 
-phylink_uninit:
-	lan78xx_phy_uninit(dev);
+disconnect_phylink:
+	phylink_disconnect_phy(dev->phylink);
+destroy_phylink:
+	phylink_destroy(dev->phylink);
 
 	return ret;
 }
-- 
2.53.0

AW: assert in phylink.c with lan7801 and dp83tc811 since kernel 6.18

[Sven Schuchmann]

Hello Andrew

> Von: Andrew Lunn <andrew@lunn.ch>
> Gesendet: Mittwoch, 06. Mai 2026 15:15
> An: Sven Schuchmann <schuchmann@schleissheimer.de>
> Cc: netdev@vger.kernel.org <netdev@vger.kernel.org>
> Betreff: Re: assert in phylink.c with lan7801 and dp83tc811 since kernel 6.18
>
> [...]
>
> Please try this patch.
>
>      Andrew

> From ea55645b23092a0de7aa3ab0eaf7bcb73a7fb0e1 Mon Sep 17 00:00:00 2001
> From: Andrew Lunn <andrew@lunn.ch>
> Date: Wed, 6 May 2026 08:10:29 -0500
> Subject: [PATCH] net: usb: lan78xx: Fix cleanup in lan78xx_phy_init
>
> If phylink_connect_phy() fails, phylink_disconnect() should not be
> called. Rather than use lan78xx_phy_uninit() which does too much, add
> the cleanup at the end of the function and only undo what was
> successfully done.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
>
> ---
>  drivers/net/usb/lan78xx.c | 14 ++++++++------
>  1 file changed, 8 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c
> index bcf293ea1bd3..9cfc122d76ef 100644
> --- a/drivers/net/usb/lan78xx.c
> +++ b/drivers/net/usb/lan78xx.c
> @@ -2842,7 +2842,7 @@ static int lan78xx_phy_init(struct lan78xx_net *dev)
>  
>          ret = lan78xx_mac_prepare_for_phy(dev);
>          if (ret < 0)
> -               goto phylink_uninit;
> +               goto destroy_phylink;
>  
>          /* If no PHY is found, set up a fixed link. It is very specific to
>           * the LAN7801 and is used in special cases like EVB-KSZ9897-1 where
> @@ -2852,7 +2852,7 @@ static int lan78xx_phy_init(struct lan78xx_net *dev)
>          if (!phydev) {
>                  ret = lan78xx_set_fixed_link(dev);
>                  if (ret < 0)
> -                       goto phylink_uninit;
> +                       goto destroy_phylink;
>  
>                  /* No PHY found, so set up a fixed link and return early.
>                   * No need to configure PHY IRQ or attach to phylink.
> @@ -2871,17 +2871,19 @@ static int lan78xx_phy_init(struct lan78xx_net *dev)
>          if (ret) {
>                  netdev_err(dev->net, "can't attach PHY to %s, error %pe\n",
>                             dev->mdiobus->id, ERR_PTR(ret));
> -               goto phylink_uninit;
> +               goto destroy_phylink;
>         }
>  
>          ret = lan78xx_configure_leds_from_dt(dev, phydev);
> 
>      if (ret < 0)
> -               goto phylink_uninit;
> +               goto disconnect_phylink;
>  
>          return 0;
>  
> -phylink_uninit:
> -       lan78xx_phy_uninit(dev);
> 
> +disconnect_phylink:
> +       phylink_disconnect_phy(dev->phylink);
> +destroy_phylink:
> +       phylink_destroy(dev->phylink);
> 
>          return ret;
>  }
> --
> 2.53.0

This prevents the crash. I think this is the fix for the RTNL Problem. Thank you!
But as you already said it is not giving me working ethernet. Will answer in another email.

Regards,

   Sven

AW: assert in phylink.c with lan7801 and dp83tc811 since kernel 6.18

[Sven Schuchmann]

Hi Andrew,

I came up with this:

diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c
index 261af300ab00..734cb62a1043 100644
--- a/drivers/net/usb/lan78xx.c
+++ b/drivers/net/usb/lan78xx.c
@@ -2862,7 +2862,9 @@ static int lan78xx_phylink_setup(struct lan78xx_net *dev)
 static void lan78xx_phy_uninit(struct lan78xx_net *dev)
 {
        if (dev->phylink) {
+               rtnl_lock();
                phylink_disconnect_phy(dev->phylink);
+               rtnl_unlock();
                phylink_destroy(dev->phylink);
                dev->phylink = NULL;
        }

and it seems to prevent the cash. What do you think?


Reards,

   Sven

Von: Andrew Lunn <andrew@lunn.ch>
Gesendet: Dienstag, 05. Mai 2026 15:13
An: Sven Schuchmann <schuchmann@schleissheimer.de>
Cc: netdev@vger.kernel.org <netdev@vger.kernel.org>
Betreff: Re: assert in phylink.c with lan7801 and dp83tc811 since kernel 6.18


On Tue, May 05, 2026 at 09:53:06AM +0000, Sven Schuchmann wrote:

> Hello,
> I have a raspberrypi and switched from kernel 6.12 to 6.18 and now I have a crash in phylink.c.

Please could you try 7.0.3, or better still, 7.1-rcX. We need to
determine if the problem has already been fixed and just needs
backporting, or is it a new problem.

> I am using a MAC:lan7801 and PHY:dp83tc811 and now it crashes like this:
>
> [    3.019174] usb 1-1.3: New USB device found, idVendor=0424, idProduct=7801, bcdDevice= 3.00
> [    3.021152] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> [    3.023192] usb 1-1.3: Product: LAN7801
> [    3.025019] usb 1-1.3: Manufacturer: Microchip
> [    3.026772] usb 1-1.3: SerialNumber: 00800F780100
> [    3.078542] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): int urb period 64
> [    3.091434] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): validation of rgmii-id with support 0000000,00000000,00000000,00006280 and advertis                                      ement 0000000,00000000,00000000,00006280 failed: -EINVAL

This appears to be the real problem.

> [    3.098928] lan78xx 1-1.3:1.0 (unnamed net_device) (uninitialized): can't attach PHY to usb-001:004, error -EINVAL
> [    3.101094] ------------[ cut here ]------------
> [    3.103163] RTNL: assertion failed at drivers/net/phy/phylink.c (2337)

and this is a knock on problem, which normally you don't see.
Please could you make line 1 of drivers/net/phy/phylink.c.

#define DEBUG 1

That will give us additional debug info.

     Andrew

Re: assert in phylink.c with lan7801 and dp83tc811 since kernel 6.18

[Andrew Lunn]

On Wed, May 06, 2026 at 12:30:33PM +0000, Sven Schuchmann wrote:
> Hi Andrew,
> 
> I came up with this:
> 
> diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c
> index 261af300ab00..734cb62a1043 100644
> --- a/drivers/net/usb/lan78xx.c
> +++ b/drivers/net/usb/lan78xx.c
> @@ -2862,7 +2862,9 @@ static int lan78xx_phylink_setup(struct lan78xx_net *dev)
>  static void lan78xx_phy_uninit(struct lan78xx_net *dev)
>  {
>         if (dev->phylink) {
> +               rtnl_lock();
>                 phylink_disconnect_phy(dev->phylink);
> +               rtnl_unlock();
>                 phylink_destroy(dev->phylink);
>                 dev->phylink = NULL;
>         }
> 
> and it seems to prevent the cash. What do you think?

Does the Ethernet also work?

As i said, there appears to be two things going on. For some reason it
decides the PHY and MAC don't make a valid combination and returns
-EINVAL.

And then we have the RTNL problem.

We should fix the RTNL problem, but that on its own will probably not
give you working Ethernet.

Right let me look at the context we are in when
phylink_disconnect_phy() is called. See if this fix is correct.

	Andrew