From: Jakub Kicinski <kuba@kernel.org>
To: Maxime Chevallier <maxime.chevallier@bootlin.com>
Cc: davem@davemloft.net, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, thomas.petazzoni@bootlin.com,
"Andrew Lunn" <andrew@lunn.ch>,
"Eric Dumazet" <edumazet@google.com>,
"Paolo Abeni" <pabeni@redhat.com>,
"Russell King" <linux@armlinux.org.uk>,
linux-arm-kernel@lists.infradead.org,
"Christophe Leroy" <christophe.leroy@csgroup.eu>,
"Herve Codina" <herve.codina@bootlin.com>,
"Florian Fainelli" <f.fainelli@gmail.com>,
"Heiner Kallweit" <hkallweit1@gmail.com>,
"Vladimir Oltean" <vladimir.oltean@nxp.com>,
"Köry Maincent" <kory.maincent@bootlin.com>,
"Jesse Brandeburg" <jesse.brandeburg@intel.com>,
"Jonathan Corbet" <corbet@lwn.net>,
"Marek Behún" <kabel@kernel.org>,
"Piergiorgio Beruto" <piergiorgio.beruto@gmail.com>,
"Oleksij Rempel" <o.rempel@pengutronix.de>,
"Nicolò Veronese" <nicveronese@gmail.com>,
"Simon Horman" <horms@kernel.org>,
mwojtas@chromium.org
Subject: Re: [PATCH net-next v10 13/13] Documentation: networking: document phy_link_topology
Date: Fri, 8 Mar 2024 21:27:04 -0800 [thread overview]
Message-ID: <20240308212704.02766ff6@kernel.org> (raw)
In-Reply-To: <20240304151011.1610175-14-maxime.chevallier@bootlin.com>
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) |
> + +-----+ +-----------------------+ +--------------+
prev parent reply other threads:[~2024-03-09 5:27 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-04 15:09 [PATCH net-next v10 00/13] Introduce PHY listing and link_topology tracking Maxime Chevallier
2024-03-04 15:09 ` [PATCH net-next v10 01/13] net: phy: Introduce ethernet link topology representation Maxime Chevallier
2024-03-04 15:09 ` [PATCH net-next v10 02/13] net: sfp: pass the phy_device when disconnecting an sfp module's PHY Maxime Chevallier
2024-03-04 15:09 ` [PATCH net-next v10 03/13] net: phy: add helpers to handle sfp phy connect/disconnect Maxime Chevallier
2024-03-04 15:10 ` [PATCH net-next v10 04/13] net: sfp: Add helper to return the SFP bus name Maxime Chevallier
2024-03-04 15:10 ` [PATCH net-next v10 05/13] net: ethtool: Allow passing a phy index for some commands Maxime Chevallier
2024-03-09 5:01 ` Jakub Kicinski
2024-03-04 15:10 ` [PATCH net-next v10 06/13] netlink: specs: add phy-index as a header parameter Maxime Chevallier
2024-03-04 15:10 ` [PATCH net-next v10 07/13] net: ethtool: Introduce a command to list PHYs on an interface Maxime Chevallier
2024-03-09 5:18 ` Jakub Kicinski
2024-04-04 8:38 ` Maxime Chevallier
2024-03-04 15:10 ` [PATCH net-next v10 08/13] netlink: specs: add ethnl PHY_GET command set Maxime Chevallier
2024-03-04 15:10 ` [PATCH net-next v10 09/13] net: ethtool: plca: Target the command to the requested PHY Maxime Chevallier
2024-03-04 15:10 ` [PATCH net-next v10 10/13] net: ethtool: pse-pd: " Maxime Chevallier
2024-03-04 15:10 ` [PATCH net-next v10 11/13] net: ethtool: cable-test: " Maxime Chevallier
2024-03-04 15:10 ` [PATCH net-next v10 12/13] net: ethtool: strset: Allow querying phy stats by index Maxime Chevallier
2024-03-04 15:10 ` [PATCH net-next v10 13/13] Documentation: networking: document phy_link_topology Maxime Chevallier
2024-03-09 5:27 ` Jakub Kicinski [this message]
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=20240308212704.02766ff6@kernel.org \
--to=kuba@kernel.org \
--cc=andrew@lunn.ch \
--cc=christophe.leroy@csgroup.eu \
--cc=corbet@lwn.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=f.fainelli@gmail.com \
--cc=herve.codina@bootlin.com \
--cc=hkallweit1@gmail.com \
--cc=horms@kernel.org \
--cc=jesse.brandeburg@intel.com \
--cc=kabel@kernel.org \
--cc=kory.maincent@bootlin.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=maxime.chevallier@bootlin.com \
--cc=mwojtas@chromium.org \
--cc=netdev@vger.kernel.org \
--cc=nicveronese@gmail.com \
--cc=o.rempel@pengutronix.de \
--cc=pabeni@redhat.com \
--cc=piergiorgio.beruto@gmail.com \
--cc=thomas.petazzoni@bootlin.com \
--cc=vladimir.oltean@nxp.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).