Re: [EXT] Re: [PATCH v3 1/1] net: phylink: add phylink_set_mac_pm() helper

["Russell King (Oracle)" <linux@armlinux.org.uk>]

On Mon, Oct 10, 2022 at 04:11:36PM +0000, Shenwei Wang wrote:
> 
> 
> > -----Original Message-----
> > From: Russell King <linux@armlinux.org.uk>
> > Sent: Monday, October 10, 2022 10:23 AM
> > To: Shenwei Wang <shenwei.wang@nxp.com>
> > Cc: Andrew Lunn <andrew@lunn.ch>; Heiner Kallweit <hkallweit1@gmail.com>;
> > David S. Miller <davem@davemloft.net>; Eric Dumazet
> > > > with an accessible PHY, what should happen if the system goes into a low
> > power state?
> > > >
> > >
> > > In theory, the SFP should be covered by this patch too. Since the
> > > resume flow is Controlled by the value of phydev->mac_managed_pm, it
> > > should work in the same way after the phydev is linked to the SFP phy instance.
> > 
> > It won't, because the MAC doesn't know when it needs to call your new function.
> > 
> > Given this, I think a different approach is needed here:
> > 
> > 1) require a MAC to call this function after phylink_create() and record
> >    the configuration in struct phylink, or put a configuration boolean in
> >    the phylink_config structure (probably better).
> > 
> 
> I prefer to use the function call because it is simple to implement and is easy to use.

	blah->phylink_config.mac_managed_pm = true;

in the appropriate drivers before they call phylink_create() would be
difficult to use?

Given that we use this method to configure the MAC speeds and phy
interface modes already, I'm not sure why we'd want some other approach
for this.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!