RE: [PATCH net-next] net: phy: call phy_init_hw() in phy resume path

Biju Das
2026-04-10T16:41:14Z

Hi Andrew,

> -----Original Message-----
> From: Andrew Lunn <andrew@lunn.ch>
> Sent: 10 April 2026 16:15
> Subject: Re: [PATCH net-next] net: phy: call phy_init_hw() in phy resume path
>
> > Apart from that, looks fine to me - it seems some paths call
> > phy_init_hw() can be called with or without phydev->lock held, and
> > this one will call it with the lock held which seems to be okay.
>
> Haven't we had deadlocks in this area before?
>
> Please test with CONFIG_PROVE_LOCKING enabled.

I have n't faced any issue with micrel phy. But my collegue
got the below issue with Microsemi phy. It doesn't finish the boot.

drivers/net/phy/mscc/mscc_main.c

[ 5.125699] ============================================
[ 5.131849] WARNING: possible recursive locking detected
[ 5.137996] 7.0.0-rc7-next-20260409+ #614 Not tainted
[ 5.143847] --------------------------------------------
[ 5.149991] swapper/0/1 is trying to acquire lock:
[ 5.155333] ffff000182bbe7c0 (&dev->lock#2){+.+.}-{4:4}, at: vsc85xx_config_init+0x68/0x344
[ 5.164771]
[ 5.164771] but task is already holding lock:
[ 5.171520] ffff000182bbe7c0 (&dev->lock#2){+.+.}-{4:4}, at: phy_attach_direct+0x19c/0x3d0
[ 5.180984]
[ 5.180984] other info that might help us debug this:
[ 5.188237] Possible unsafe locking scenario:
[ 5.188237]
[ 5.195089] CPU0
[ 5.197914] ----
[ 5.200670] lock(&dev->lock#2);
[ 5.204425] lock(&dev->lock#2);
[ 5.208273]
[ 5.208273] *** DEADLOCK ***
[ 5.208273]
[ 5.214920] May be due to missing lock nesting notation
[ 5.214920]
[ 5.222677] 2 locks held by swapper/0/1:
[ 5.227217] #0: ffff800082f051f0 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_lock+0x1c/0x28
[ 5.236041] #1: ffff000182bbe7c0 (&dev->lock#2){+.+.}-{4:4}, at: phy_attach_direct+0x19c/0x3d0
[ 5.245880]
[ 5.245880] stack backtrace:
[ 5.250824] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 7.0.0-rc7-next-20260409+ #614 PREEMPT
[ 5.250840] Hardware name: Renesas RZ/T2H EVK Board based on r9a09g077m44 (DT)
[ 5.250847] Call trace:
[ 5.250853] show_stack+0x18/0x30 (C)
[ 5.250876] dump_stack_lvl+0x70/0x98
[ 5.250894] dump_stack+0x18/0x24
[ 5.250910] print_deadlock_bug+0x220/0x234
[ 5.250931] __lock_acquire+0xe10/0x1594
[ 5.250950] lock_acquire+0x284/0x400
[ 5.250967] __mutex_lock+0xa8/0x804
[ 5.250983] mutex_lock_nested+0x24/0x3c
[ 5.250998] vsc85xx_config_init+0x68/0x344
[ 5.251013] phy_init_hw+0x68/0xa8
[ 5.251030] __phy_resume+0x3c/0x98
[ 5.251047] phy_attach_direct+0x1a4/0x3d0
[ 5.251064] phylink_fwnode_phy_connect+0x98/0x140
[ 5.251085] stmmac_open+0x120/0x38c
[ 5.251103] __dev_open+0x13c/0x280
[ 5.251117] __dev_change_flags+0x19c/0x21c
[ 5.251131] netif_change_flags+0x24/0x6c
[ 5.251144] dev_change_flags+0x48/0x80
[ 5.251159] ip_auto_config+0x264/0xec0
[ 5.251176] do_one_initcall+0x7c/0x4d0
[ 5.251194] kernel_init_freeable+0x2b4/0x33c
[ 5.251212] kernel_init+0x24/0x140
[ 5.251231] ret_from_fork+0x10/0x20

Cheers,
Biju