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

Biju Das
2026-04-10T15:38:41Z

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