netdev - RE: [RFC PATCH net-next] net: phy: Don't suspend/resume device not in use

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID:
 <AM9PR04MB8506A1FC6679E96B34F21E94E2202@AM9PR04MB8506.eurprd04.prod.outlook.com>
Date: Thu, 7 Mar 2024 16:44:58 +0000
From: "Jan Petrous (OSS)" <jan.petrous@....nxp.com>
To: Andrew Lunn <andrew@...n.ch>, "Jan Petrous (OSS)"
	<jan.petrous@....nxp.com>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>, Heiner Kallweit
	<hkallweit1@...il.com>, Russell King <linux@...linux.org.uk>, "David S.
 Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Jakub
 Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>
Subject: RE: [RFC PATCH net-next] net: phy: Don't suspend/resume device not in
 use

> 
> > Because such device didn't go through attach process, internal
> > parameters like phy_dev->interface is set to the default value, which
> > is not correct for some drivers. Ie. Aquantia PHY AQR107 doesn't
> > support PHY_INTERFACE_MODE_GMII and trying to use phy_init_hw()
> > in mdio_bus_phy_resume() ends up with the following error caused
> > by initial check of supported interfaces in aqr107_config_init():
> >
> > [   63.927708] Aquantia AQR113C stmmac-0:08: PM: failed to resume: error -
> 19']
> >
> > Signed-off-by: Jan Petrous <jan.petrous@....nxp.com>
> > ---
> >  drivers/net/phy/phy_device.c | 8 ++++++++
> >  1 file changed, 8 insertions(+)
> >
> > diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> > index 3611ea64875e..30c03ac6b84c 100644
> > --- a/drivers/net/phy/phy_device.c
> > +++ b/drivers/net/phy/phy_device.c
> > @@ -311,6 +311,10 @@ static __maybe_unused int
> mdio_bus_phy_suspend(struct device *dev)
> >  {
> >         struct phy_device *phydev = to_phy_device(dev);
> >
> > +       /* Don't suspend device if not in use state */
> > +       if (phydev->state <= PHY_READY)
> > +               return 0;
> > +
> >         if (phydev->mac_managed_pm)
> >                 return 0;
> 
> If nothing is using it, suspending it does however make sense. It is
> consuming power, which could be saved by suspending it. It makes the
> code asymmetrical, but i would throw this hunk away.

Yes, I also thought about still having possibility to suspend it, even not used.
I'm ok with removal the hunk.

> 
> >
> > @@ -344,6 +348,10 @@ static __maybe_unused int
> mdio_bus_phy_resume(struct device *dev)
> >         struct phy_device *phydev = to_phy_device(dev);
> >         int ret;
> >
> > +       /* Don't resume device which wasn't previously in use state */
> > +       if (phydev->state <= PHY_READY)
> > +               return 0;
> > +
> 
> This is the real fix to your problem. phy_attach_direct() also does a
> phy_resume(), so if the device does come along and claim the PHY after
> the resume, it looks like this should work, without the matching
> suspend.

Well, I like symmetry, this was the reason I checked both PM directions.
But you are right, it works for me with resume hunk only.

Thanks.
/Jan