netdev - RE: [PATCH 2/4] net: phy: aquantia: Enable MAC Controlled EEE

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]

Message-ID:
 <BL3PR12MB64504E1E36E01EF76ADB3946C302A@BL3PR12MB6450.namprd12.prod.outlook.com>
Date: Mon, 24 Jul 2023 11:29:28 +0000
From: Revanth Kumar Uppala <ruppala@...dia.com>
To: Andrew Lunn <andrew@...n.ch>
CC: "linux@...linux.org.uk" <linux@...linux.org.uk>, "hkallweit1@...il.com"
	<hkallweit1@...il.com>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>, Narayan Reddy
	<narayanr@...dia.com>
Subject: RE: [PATCH 2/4] net: phy: aquantia: Enable MAC Controlled EEE



> -----Original Message-----
> From: Andrew Lunn <andrew@...n.ch>
> Sent: Wednesday, June 28, 2023 7:24 PM
> To: Revanth Kumar Uppala <ruppala@...dia.com>
> Cc: linux@...linux.org.uk; hkallweit1@...il.com; netdev@...r.kernel.org;
> linux-tegra@...r.kernel.org; Narayan Reddy <narayanr@...dia.com>
> Subject: Re: [PATCH 2/4] net: phy: aquantia: Enable MAC Controlled EEE
> 
> External email: Use caution opening links or attachments
> 
> 
> On Wed, Jun 28, 2023 at 06:13:24PM +0530, Revanth Kumar Uppala wrote:
> > Enable MAC controlled energy efficient ethernet (EEE) so that MAC can
> > keep the PHY in EEE sleep mode when link utilization is low to reduce
> > energy consumption.
> 
> This needs more explanation. Is this 'SmartEEE', in that the PHY is doing EEE
> without the SoC MAC being involved?
No, this is not Smart EEE.
> 
> Ideally, you should only do SmartEEE, if the SoC MAC is dumb and does not have
> EEE itself. I guess if you are doing rate adaptation, or MACSEC in the PHY, then
> you might be forced to use SmartEEE since the SoC MAC is somewhat decoupled
> from the PHY.
> 
> At the moment, we don't have a good story for SmartEEE. It should be
> configured in the same way as normal EEE, ethtool --set-eee etc. I've got a
> rewrite of normal EEE in the works. Once that is merged i hope SmartEEE will be
> next.
"ethtool --set-eee" is a dynamic way of enabling normal EEE and here we are doing the same normal EEE but configuring it by default in aqr107_config_init() instead of doing it dynamically.
So, is there any concern for this?
Thanks,
Revanth Uppala
> 
>     Andrew