[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <PAXPR04MB9185313B299F8788906E0EE789209@PAXPR04MB9185.eurprd04.prod.outlook.com>
Date: Mon, 10 Oct 2022 16:11:36 +0000
From: Shenwei Wang <shenwei.wang@....com>
To: Russell King <linux@...linux.org.uk>
CC: Andrew Lunn <andrew@...n.ch>,
Heiner Kallweit <hkallweit1@...il.com>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"imx@...ts.linux.dev" <imx@...ts.linux.dev>
Subject: RE: [EXT] Re: [PATCH v3 1/1] net: phylink: add phylink_set_mac_pm()
helper
> -----Original Message-----
> From: Russell King <linux@...linux.org.uk>
> Sent: Monday, October 10, 2022 10:23 AM
> To: Shenwei Wang <shenwei.wang@....com>
> Cc: Andrew Lunn <andrew@...n.ch>; Heiner Kallweit <hkallweit1@...il.com>;
> David S. Miller <davem@...emloft.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.
> 2) whenever any PHY is attached, check the status of this feature, and
> pass the configuration on to phylib.
>
> That means MACs don't have to keep calling the function - they declare early on
> whether they will be using MAC managed PM or not and then they're done with
> that. Keeps it simple.
>
Agree. Let me implement this idea in the next version.
Thanks,
Shenwei
> Russell.
>
> --
> RMK's Patch system:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ar
> mlinux.org.uk%2Fdeveloper%2Fpatches%2F&data=05%7C01%7Cshenwei.
> wang%40nxp.com%7C2d5aa021cfa74162a1e008daaad350cc%7C686ea1d3bc2b
> 4c6fa92cd99c5c301635%7C0%7C0%7C638010121814590052%7CUnknown%7C
> TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX
> VCI6Mn0%3D%7C3000%7C%7C%7C&sdata=vEHqzO3CSdtvSuaW80%2FaBK
> sDp895q7leiz1w%2BZNmGCU%3D&reserved=0
> FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
Powered by blists - more mailing lists