Re: [PATCH net-next v10 13/13] Documentation: networking: document phy_link_topology

[Jakub Kicinski]

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) |
> +  +-----+         +-----------------------+         +--------------+