linux-kernel - RE: [PATCH net V2 2/2] net: lan743x: support WOL in MAC even when PHY does not

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] [day] [month] [year] [list]

Message-ID: <PH8PR11MB7965D05E16D922C3B1F14E5E95162@PH8PR11MB7965.namprd11.prod.outlook.com>
Date: Fri, 26 Apr 2024 07:43:35 +0000
From: <Ronnie.Kunin@...rochip.com>
To: <andrew@...n.ch>, <Raju.Lakkaraju@...rochip.com>
CC: <netdev@...r.kernel.org>, <davem@...emloft.net>, <kuba@...nel.org>,
	<pabeni@...hat.com>, <edumazet@...gle.com>, <linux-kernel@...r.kernel.org>,
	<Bryan.Whitehead@...rochip.com>, <UNGLinuxDriver@...rochip.com>
Subject: RE: [PATCH net V2 2/2] net: lan743x: support WOL in MAC even when PHY
 does not

Agreed about the tradeoff. 

>From your previous entry in this thread:
>Renegotiation does take a little over 1s. It maybe not worth it for suspend to RAM. But for suspend to disk, a resume is probably going to take awhile, so maybe 1 second is less noticeable.
With some of the partner PHYs we've used, specially when supporting higher speeds such as 2.5G we had seen even much longer renegotiation times, reaching as much as 6-7 seconds in some cases.  

Raju,
Due to the above and some of the other issues you mentioned you are facing (i.e. undesired wakes on intermediate link changes that you would need to "filter out" ) , I'd  rather not try to further optimize phy power consumption by down-speeding the link at this time, and keep fast resume time and overall simplicity the priority. If/when customers request it or power regulatory norms (EU as mentioned by Andrew) make it a must have we can always revisit it. That being said, after verifying wake functionality is correct as the first priority, please do look into turning off anything in the LAN743x  and PCI11x1x devices that is not needed while asleep before completing the suspend.

Thanks,
Ronnie 

> -----Original Message-----
> From: Andrew Lunn <andrew@...n.ch>
> Sent: Thursday, April 25, 2024 10:13 AM
> To: Raju Lakkaraju - I30499 <Raju.Lakkaraju@...rochip.com>
> Cc: netdev@...r.kernel.org; davem@...emloft.net; kuba@...nel.org; pabeni@...hat.com;
> edumazet@...gle.com; linux-kernel@...r.kernel.org; Bryan Whitehead - C21958
> <Bryan.Whitehead@...rochip.com>; UNGLinuxDriver <UNGLinuxDriver@...rochipcom>
> Subject: Re: [PATCH net V2 2/2] net: lan743x: support WOL in MAC even when PHY does not
> 
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> > If PHY handles the magic packet or phy activity (i.e. WAKE_MAGIC or WAKE_PHY), our PCI11x1x's
> MAC will handle only interrupt (MDINT from PHY). Not MAC's magic packet.
> > In this case do we really call phy_speed_down( ) ?
> 
> phy_speed_down() is orthogonal to who does the wake. Packets are packets. phy_speed_down() does
> not change that. All it does it drop the link to a slower speed. And slower speed means less power
> consumption. A PHY operating at 10Mbps uses about 1W less power than a PHY operating at 1G. The
> numbers will depend on the PHY, but you get the idea. Plus the link peer will also save a similar amount
> out power....
> 
> If the MAC is needed for WoL, because the PHY does not support the needed modes, you probably also
> save power with the MAC running at 10Mbps. Its clocks probably tick slower, etc.
> 
> But there is a trade off. When resuming, you want to go back to the full speed link. And that takes time,
> a little over 1 second. So you need to decide, do you want to prioritise minimum power consumption
> when suspended, or fast resume?
> 
>      Andrew