From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Oleksij Rempel <o.rempel@pengutronix.de>,
Woojung Huh <woojung.huh@microchip.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Heiner Kallweit <hkallweit1@gmail.com>,
kernel@pengutronix.de, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, UNGLinuxDriver@microchip.com,
Simon Horman <horms@kernel.org>,
Maxime Chevallier <maxime.chevallier@bootlin.com>
Subject: Re: [PATCH net-next v1 4/4] net: phy: Always read EEE LPA in genphy_c45_ethtool_get_eee()
Date: Thu, 24 Apr 2025 15:47:03 +0100 [thread overview]
Message-ID: <aApO59e6I6uLaw2P@shell.armlinux.org.uk> (raw)
In-Reply-To: <8f0d5725-04b7-4e15-897d-1fd5e540dacb@lunn.ch>
On Thu, Apr 24, 2025 at 04:34:27PM +0200, Andrew Lunn wrote:
> On Thu, Apr 24, 2025 at 02:16:01PM +0100, Russell King (Oracle) wrote:
> > However, I've no objection to reading the LPA EEE state and
> > reporting it.
>
> What happens with normal link mode LPA when autoneg is disabled? I
> guess they are not reported because the PHY is not even listening for
> the autoneg pulses. We could be inconsistent between normal LPA and
> LPA EEE, but is that a good idea?
With autoneg state, that controls whether the various pages get
exchanged or not - which includes the EEE capabilties. This is the
big hammer for anything that is negotiated.
With EEE, as long as autoneg in the main config is true, the PHY will
exchange the EEE capability pages if it supports them. Our eee_enabled
is purely just a software switch, there's nothing that corresponds to it
in hardware, unlike autoneg which has a bit in BMCR.
We implement eee_enabled by clearing the advertisement in the hardware
but accepting (and remembering) the advertisement from userspace
unmodified.
The two things are entirely different in hardware.
Since:
ethtool --set-eee eee off
Will use ETHTOOL_GEEE, modify eee_enabled to be false (via
do_generic_set), and then use ETHTOOL_SEEE to write it back, the
old advertisement will be passed back to the kernel in this case.
If we don't preserve the advertisement, then:
ethtool --set-eee eee off
will clear the advertisement, and then:
ethtool --set-eee eee on
will set eee_enabled true but we'll have an empty advertisement. Not
ideal.
If we think about forcing it for an empty advertisement to e.g. fully
populated, then:
ethtool --set-eee eee on advertise 0
will surprisingly not end up with an empty advertisement.
So, I don't think it's realistic to come up with a way that --set-eee
behaves the same way as -s because of the way ethtool has been
implemented.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
next prev parent reply other threads:[~2025-04-24 14:47 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-24 13:02 [PATCH net-next v1 0/4] Improve EEE control for KSZ switches and clarify ethtool output Oleksij Rempel
2025-04-24 13:02 ` [PATCH net-next v1 1/4] net: dsa: user: Skip set_mac_eee() if support_eee() is implemented Oleksij Rempel
2025-04-24 13:11 ` Russell King (Oracle)
2025-04-24 13:02 ` [PATCH net-next v1 2/4] net: dsa: microchip: Remove set_mac_eee() callback from KSZ driver Oleksij Rempel
2025-04-24 13:02 ` [PATCH net-next v1 3/4] net: phy: Don't report advertised EEE modes if EEE is disabled Oleksij Rempel
2025-04-24 13:14 ` Russell King (Oracle)
2025-04-24 14:30 ` Andrew Lunn
2025-04-24 14:38 ` Russell King (Oracle)
2025-04-24 13:02 ` [PATCH net-next v1 4/4] net: phy: Always read EEE LPA in genphy_c45_ethtool_get_eee() Oleksij Rempel
2025-04-24 13:16 ` Russell King (Oracle)
2025-04-24 14:34 ` Andrew Lunn
2025-04-24 14:47 ` Russell King (Oracle) [this message]
2025-04-25 4:41 ` Oleksij Rempel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aApO59e6I6uLaw2P@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=UNGLinuxDriver@microchip.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hkallweit1@gmail.com \
--cc=horms@kernel.org \
--cc=kernel@pengutronix.de \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maxime.chevallier@bootlin.com \
--cc=netdev@vger.kernel.org \
--cc=o.rempel@pengutronix.de \
--cc=pabeni@redhat.com \
--cc=woojung.huh@microchip.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).