netdev - Re: [PATCH RFC 08/13] phylink: add phylink infrastructure

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:   Tue, 1 Aug 2017 16:34:46 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Russell King <rmk+kernel@....linux.org.uk>
Cc:     Florian Fainelli <f.fainelli@...il.com>, netdev@...r.kernel.org
Subject: Re: [PATCH RFC 08/13] phylink: add phylink infrastructure

On Tue, Jul 25, 2017 at 03:03:13PM +0100, Russell King wrote:
> The link between the ethernet MAC and its PHY has become more complex
> as the interface evolves.  This is especially true with serdes links,
> where the part of the PHY is effectively integrated into the MAC.
> 
> Serdes links can be connected to a variety of devices, including SFF
> modules soldered down onto the board with the MAC, a SFP cage with
> a hotpluggable SFP module which may contain a PHY or directly modulate
> the serdes signals onto optical media with or without a PHY, or even
> a classical PHY connection.
> 
> Moreover, the negotiation information on serdes links comes in two
> varieties - SGMII mode, where the PHY provides its speed/duplex/flow
> control information to the MAC, and 1000base-X mode where both ends
> exchange their abilities and each resolve the link capabilities.
> 
> This means we need a more flexible means to support these arrangements,
> particularly with the hotpluggable nature of SFP, where the PHY can
> be attached or detached after the network device has been brought up.
> 
> Ethtool information can come from multiple sources:
> - we may have a PHY operating in either SGMII or 1000base-X mode, in
>   which case we take ethtool/mii data directly from the PHY.
> - we may have a optical SFP module without a PHY, with the MAC
>   operating in 1000base-X mode - the ethtool/mii data needs to come
>   from the MAC.
> - we may have a copper SFP module with a PHY whic can't be accessed,
>   which means we need to take ethtool/mii data from the MAC.
> 
> Phylink aims to solve this by providing an intermediary between the
> MAC and PHY, providing a safe way for PHYs to be hotplugged, and
> allowing a SFP driver to reconfigure the serdes connection.
> 
> Phylink also takes over support of fixed link connections, where the
> speed/duplex/flow control are fixed, but link status may be controlled
> by a GPIO signal.  By avoiding the fixed-phy implementation, phylink
> can provide a faster response to link events: fixed-phy has to wait for
> phylib to operate its state machine, which can take several seconds.
> In comparison, phylink takes milliseconds.
> 
> Signed-off-by: Russell King <rmk+kernel@....linux.org.uk>

Reviewed-by: Andrew Lunn <andrew@...n.ch>

    Andrew