[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240308212704.02766ff6@kernel.org>
Date: Fri, 8 Mar 2024 21:27:04 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Maxime Chevallier <maxime.chevallier@...tlin.com>
Cc: davem@...emloft.net, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, thomas.petazzoni@...tlin.com, Andrew Lunn
<andrew@...n.ch>, Eric Dumazet <edumazet@...gle.com>, Paolo Abeni
<pabeni@...hat.com>, Russell King <linux@...linux.org.uk>,
linux-arm-kernel@...ts.infradead.org, Christophe Leroy
<christophe.leroy@...roup.eu>, Herve Codina <herve.codina@...tlin.com>,
Florian Fainelli <f.fainelli@...il.com>, Heiner Kallweit
<hkallweit1@...il.com>, Vladimir Oltean <vladimir.oltean@....com>,
Köry Maincent <kory.maincent@...tlin.com>, Jesse Brandeburg
<jesse.brandeburg@...el.com>, Jonathan Corbet <corbet@....net>, Marek
Behún <kabel@...nel.org>, Piergiorgio Beruto
<piergiorgio.beruto@...il.com>, Oleksij Rempel <o.rempel@...gutronix.de>,
Nicolò Veronese <nicveronese@...il.com>, Simon Horman
<horms@...nel.org>, mwojtas@...omium.org
Subject: Re: [PATCH net-next v10 13/13] Documentation: networking: document
phy_link_topology
We should :ref: to this doc from the PHY_GET in the ethtool one as well?
On Mon, 4 Mar 2024 16:10:09 +0100 Maxime Chevallier wrote:
> +An Ethernet Interface from userspace's point of view is nothing but a
interface
> +:c:type:`struct net_device <net_device>`, which exposes configuration options
> +through the legacy ioctls and the ethool netlink commands. The base assumption
ethtool
> +when designing these configuration channels were that the link looked
nit: s/channels/APIs/ channels sometimes means IRQs/queues in netdev :S
s/looked/looks/
> +something like this ::
s/this//
> + +-----------------------+ +----------+ +--------------+
> + | Ethernet Controller / | | Ethernet | | Connector / |
> + | MAC | ------ | PHY | ---- | Port | ---... to LP
> + +-----------------------+ +----------+ +--------------+
> + struct net_device struct phy_device
> +
> +Commands that needs to configure the PHY will go through the net_device.phydev
> +field to reach the PHY and perform the relevant configuration.
> +
> +This assumption falls apart in more complex topologies that can arise when,
> +for example, using SFP transceivers (although that's not the only specific case).
s/specific/such/
> +Here, we have 2 basic scenarios. Either the MAC is able to output a serialized
> +interface, that can directly be fed to an SFP cage, such as SGMII, 1000BaseX,
> +10GBaseR, etc.
The "Either" makes me expect and "or" at some state in this paragraph..
> +The link topology then looks like this (when an SFP module is inserted) ::
> +
> + +-----+ SGMII +------------+
> + | MAC | ------- | SFP Module |
> + +-----+ +------------+
> +
> +Knowing that some modules embed a PHY, the actual link is more like ::
> +
> + +-----+ SGMII +--------------+
> + | MAC | -------- | PHY (on SFP) |
> + +-----+ +--------------+
> +
> +In this case, the SFP PHY is handled by phylib, and registered by phylink through
> +its SFP upstream ops.
> +
> +Now some Ethernet controllers aren't able to output a serialized interface, so
> +we can't directly connect them to an SFP cage. However, some PHYs can be used
s/However, some/In such cases, certain/
> +as media-converters, to translate the non-serialized MAC MII interface to a
> +serialized MII interface fed to the SFP ::
> +
> + +-----+ RGMII +-----------------------+ SGMII +--------------+
> + | MAC | ------- | PHY (media converter) | ------- | PHY (on SFP) |
> + +-----+ +-----------------------+ +--------------+
Powered by blists - more mailing lists