netdev - RE: [PATCH] net: stmmac: fix MAC not working when system resume back with WoL enabled

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 for Android: free password hash cracker in your pocket

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

Message-ID: <DB8PR04MB67954F4650408025E6D4EE2AE6CE9@DB8PR04MB6795.eurprd04.prod.outlook.com>
Date:   Thu, 2 Sep 2021 10:26:13 +0000
From:   Joakim Zhang <qiangqing.zhang@....com>
To:     Russell King <linux@...linux.org.uk>
CC:     Vladimir Oltean <olteanv@...il.com>,
        "peppe.cavallaro@...com" <peppe.cavallaro@...com>,
        "alexandre.torgue@...s.st.com" <alexandre.torgue@...s.st.com>,
        "joabreu@...opsys.com" <joabreu@...opsys.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "mcoquelin.stm32@...il.com" <mcoquelin.stm32@...il.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "andrew@...n.ch" <andrew@...n.ch>,
        "f.fainelli@...il.com" <f.fainelli@...il.com>,
        "hkallweit1@...il.com" <hkallweit1@...il.com>,
        dl-linux-imx <linux-imx@....com>
Subject: RE: [PATCH] net: stmmac: fix MAC not working when system resume back
 with WoL enabled


Hi Russell,

Thanks a lot!

> -----Original Message-----
> From: Russell King <linux@...linux.org.uk>
> Sent: 2021年9月2日 16:32
> To: Joakim Zhang <qiangqing.zhang@....com>
> Cc: Vladimir Oltean <olteanv@...il.com>; peppe.cavallaro@...com;
> alexandre.torgue@...s.st.com; joabreu@...opsys.com;
> davem@...emloft.net; kuba@...nel.org; mcoquelin.stm32@...il.com;
> netdev@...r.kernel.org; andrew@...n.ch; f.fainelli@...il.com;
> hkallweit1@...il.com; dl-linux-imx <linux-imx@....com>
> Subject: Re: [PATCH] net: stmmac: fix MAC not working when system resume
> back with WoL enabled
> 
> On Thu, Sep 02, 2021 at 07:28:44AM +0000, Joakim Zhang wrote:
> >
> > Hi Russell,
> >
> > > -----Original Message-----
> > > From: Russell King <linux@...linux.org.uk>
> > > Sent: 2021年9月1日 21:26
> > > To: Joakim Zhang <qiangqing.zhang@....com>
> > > Cc: Vladimir Oltean <olteanv@...il.com>; peppe.cavallaro@...com;
> > > alexandre.torgue@...s.st.com; joabreu@...opsys.com;
> > > davem@...emloft.net; kuba@...nel.org; mcoquelin.stm32@...il.com;
> > > netdev@...r.kernel.org; andrew@...n.ch; f.fainelli@...il.com;
> > > hkallweit1@...il.com; dl-linux-imx <linux-imx@....com>
> > > Subject: Re: [PATCH] net: stmmac: fix MAC not working when system
> > > resume back with WoL enabled
> > >
> > > This means you need to have the phy <-> mac link up during suspend,
> > > and in that case, yes, you do not want to call
> > > phylink_stop() or phylink_start().
> >
> > I have a question here, why need to have the phy<->mac link up during
> suspend?
> 
> You need the link up because I think from reading the code, it is _not_ the PHY
> that is triggering the wakeup in the configuration you are using, but the MAC.
> 
> If the link is down, the PHY can't pass the received packet to the MAC, and the
> MAC can't recognise the magic packet.

Per my understanding, if use PHY-based wakeup, PHY should be active, and MAC can be
totally suspended. When PHY receive the magic packets, it will generate a signal via wakeup
PIN (PHY seems all have such PIN) to inform SoC, we can use this to wake up the system.
Please correct me if I misunderstand.

> FEC doesn't have this. FEC relies purely on the PHY detecting the magic packet,
> which is much more power efficient, because it means the MAC doesn't need
> to be powered up and operational while the rest of the system is suspended.

AFAIK, FEC also use the MAC-based wakeup, when enable FEC WoL feature, it will
keep MAC receive logic active, PHY pass the received packets to MAC, if MAC detects
the magic packets, it will generate an interrupt to wake up the system.

Below is the block guide description:
To put the MAC in Sleep mode, set ENETn_ECR[SLEEP]. At the same time
ENETn_ECR[MAGICEN] should also be set to enable magic packet detection.
In addition, when the processor is in Stop mode, Sleep mode is entered, without affecting
the ENETn_ECR register bits.
When the core is in Sleep mode:
? The MAC transmit logic is disabled.
? The core FIFO receive/transmit functions are disabled.
? The MAC receive logic is kept in Normal mode, but it ignores all traffic from the
line except magic packets. They are detected so that a remote agent can wake the
node.

So FEC is MAC-based wakeup, right?

> > As you described in past thread, phylink_stop() and phylink_start()
> > also need to be called even with WoL active.
> 
> That was with the assumption that the PHY was detecting the magic packet. It
> isn't for stmmac - stmmac can be configured to bypass the configuration of the
> PHY for this and uses the MAC to detect this instead. If the MAC is doing the
> detecting for WoL, then you need network connectivity to be functional from
> the network cable through the PHY and up to the MAC.

Yes, we configure MAC detecting the WoL, I think, as long as PHY is active, it can receive
the packets then pass to MAC, MAC ignore all traffic from the line except magic packets.
So STMMAC should work the same as FEC do.

> So, bringing the link down at suspend in this case _will_ break WoL. The PHY
> isn't the device detecting the magic packet, it is the MAC, and the MAC must
> be able to see the network traffic.

I am not sure if it is the difference for phylink and phylib, may phylink has such requirement?

Best Regards,
Joakim Zhang