Hi Russell King,

> -----Original Message-----
> From: Russell King <linux@armlinux.org.uk>
> Sent: 10 April 2026 16:22
> Subject: Re: [PATCH net-next] net: phy: call phy_init_hw() in phy resume path
> 
> On Fri, Apr 10, 2026 at 05:15:21PM +0200, Andrew Lunn wrote:
> > > 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?
> 
> If we have a problem calling phy_init_hw() with phydev->lock held, then:
> 
> phy_state_machine():
>         mutex_lock(&phydev->lock);
>         state_work = _phy_state_machine(phydev);
> 
> _phy_state_machine():
> 	switch (phydev->state) {
> ...
>         case PHY_CABLETEST:
>                 err = phydev->drv->cable_test_get_status(phydev, &finished);
>                 if (err) {
>                         phy_abort_cable_test(phydev);
> 
> phy_abort_cable_test():
>         err = phy_init_hw(phydev);
> 
> that path has a problem and needs fixing.

These 3 Phy drivers are using the same lock, and it can lead to dead lock.

drivers/net/phy/microchip_t1.c
drivers/net/phy/marvell-88x2222.c
drivers/net/phy/mscc/mscc_main.c

Maybe as you said earlier, moving to phy_resume() will be safer solution.

Cheers,
Biju