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