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+ker...@arm.linux.org.uk>

Reviewed-by: Andrew Lunn <and...@lunn.ch>

    Andrew

Reply via email to