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

Date: Wed, 24 Apr 2024 14:13:31 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Ronnie.Kunin@...rochip.com
Cc: Raju.Lakkaraju@...rochip.com, 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

> > This is the bit that is missing from your commit message, and maybe it should be in a comment. The
> > interrupt controller is part of the MAC. So you need to leave MAC burning power, maybe even
> > processing packets, because you cannot disable the MAC but leave the interrupt controller functioning,
> > so that it can trigger a wake up via PCIe.
> 

> I think there is a terminology problem here. Within MCHP we
> sometimes call "the MAC" to the whole ethernet controller chip that
> has everything (i.e. actual MAC, FIFOs, filtering engines, offloads,
> interrupt controller, bus interface, etc) except the PHY.

> That is what Raju probably means when he says that the interrupt is
> handled by "the MAC". While the registers that control
> enabling/disabling processing of the phy interrupt do reside within
> the MAC block's register set in the ethernet controller, it neither
> means that the extensive parts of the actual MAC block need to be
> kept enabled nor that processing packets has to occur in the MAC in
> order for the PCI11x1x chip to detect an event coming from the PHY
> that should be processed as a wake event over PCIe

I was expecting that, which is why i suggested looking at shutting
down what is not needed.  The current lan743x_ethtool_set_wol() does
not do any of that.

> I am Windows driver expert, not Linux so I may be wrong for Linux,
> but with the advent of dynamic PM in modern OSs (connected and then
> modern standby in Windows, I remember also autosuspend - at least in
> USB, maybe not applicable to PCIe - in Linux ) we have stayed away
> from renegotiating the link to down speed during suspend - resume
> events since those interfere with / delay connectivity
> significantly.

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.

Also you maybe need to think about is EU norms about standby and power
off consumption. Going from 1G to 10M can save you 1W.

	Andrew