netdev - Re: [PATCH net] net: phylink: mac_link

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: <20250417090702.16d78e0f@fedora.home>
Date: Thu, 17 Apr 2025 09:07:02 +0200
From: Maxime Chevallier <maxime.chevallier@...tlin.com>
To: "Russell King (Oracle)" <rmk+kernel@...linux.org.uk>
Cc: Andrew Lunn <andrew@...n.ch>, Heiner Kallweit <hkallweit1@...il.com>,
 Alexander Duyck <alexander.duyck@...il.com>, "David S. Miller"
 <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski
 <kuba@...nel.org>, netdev@...r.kernel.org, Paolo Abeni <pabeni@...hat.com>
Subject: Re: [PATCH net] net: phylink: mac_link_(up|down)() clarifications

Hello Russell,

On Wed, 16 Apr 2025 22:53:19 +0100
"Russell King (Oracle)" <rmk+kernel@...linux.org.uk> wrote:

> As a result of an email from the fbnic author, I reviewed the phylink
> documentation, and I have decided to clarify the wording in the
> mac_link_(up|down)() kernel documentation as this was written from the
> point of view of mvneta/mvpp2 and is misleading.
> 
> The documentation talks about forcing the link - indeed, this is what
> is done in the mvneta and mvpp2 drivers but not at the physical layer
> but the MACs idea, which has the effect of only allowing or stopping
> packet flow at the MAC. This "link" needs to be controlled when using
> a PHY or fixed link to start or stop packet flow at the MAC. However,
> as the MAC and PCS are tightly integrated, if the MACs idea of the
> link is forced down, it has the side effect that there is no way to
> determine that the media link has come up - in this mode, the MAC must
> be allowed to follow its built-in PCS so we can read the link state.
> 
> Frame the documentation in more generic terms, to avoid the thought
> that the physical media link to the partner needs in some way to be
> forced up or down with these calls; it does not. If that were to be
> done, it would be a self-fulfilling prophecy - e.g. if the media link
> goes down, then mac_link_down() will be called, and if the media link
> is then placed into a forced down state, there is no possibility
> that the media link will ever come up again - clearly this is a wrong
> interpretation.
> 
> These methods are notifications to the MAC about what has happened to
> the media link state - either from the PHY, or a PCS, or whatever
> mechanism fixed-link is using. Thus, reword them to get away from
> talking about changing link state to avoid confusion with media link
> state.
> 
> This is not a change of any requirements of these methods.
> 
> Also, remove the obsolete references to EEE for these methods, we now
> have the LPI functions for configuring the EEE parameters which
> renders this redundant, and also makes the passing of "phy" to the
> mac_link_up() function obsolete.
> 
> Signed-off-by: Russell King (Oracle) <rmk+kernel@...linux.org.uk>

Thanks for that,

Reviewed-by: Maxime Chevallier <maxime.chevallier@...tlin.com>

Maxime