Received-SPF: pass (google.com: domain of linux-kernel+bounces-156842-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Date: Wed, 24 Apr 2024 14:13:31 +0200
From: Andrew Lunn <andrew@lunn.ch>
To: Ronnie.Kunin@microchip.com
Cc: Raju.Lakkaraju@microchip.com, netdev@vger.kernel.org,
	davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com,
	edumazet@google.com, linux-kernel@vger.kernel.org,
	Bryan.Whitehead@microchip.com, UNGLinuxDriver@microchip.com
Subject: Re: [PATCH net V2 2/2] net: lan743x: support WOL in MAC even when
 PHY does not
Message-ID: <3285a386-5c3e-445d-94d7-4157240a4eb8@lunn.ch>
References: <20240320042107.903051-1-Raju.Lakkaraju@microchip.com>
 <20240320042107.903051-3-Raju.Lakkaraju@microchip.com>
 <22089299-a3e2-4cbd-942a-65ea070657b8@lunn.ch>
 <LV8PR11MB87003ABBCA98F00F3EEA9AB09F032@LV8PR11MB8700.namprd11.prod.outlook.com>
 <fb5a6f19-ae4c-443e-babb-cbbcf6ba5fc6@lunn.ch>
 <LV8PR11MB8700A34520EA2521BC5F59EF9F112@LV8PR11MB8700.namprd11.prod.outlook.com>
 <9c4f8fcd-ae95-4874-b829-d381928c5f13@lunn.ch>
 <PH8PR11MB7965211413E7295D537BF53095102@PH8PR11MB7965.namprd11.prod.outlook.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <PH8PR11MB7965211413E7295D537BF53095102@PH8PR11MB7965.namprd11.prod.outlook.com>

> > 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