netdev - Re: [EXT] Re: [PATCH v3 1/1] net: phylink: add phylink_set_mac

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]

Date:   Mon, 10 Oct 2022 17:21:42 +0100
From:   "Russell King (Oracle)" <linux@...linux.org.uk>
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 <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

On Mon, Oct 10, 2022 at 04:11:36PM +0000, Shenwei Wang wrote:
> 
> 
> > -----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.

	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!