Re: [PATCH net-next v18 10/10] Documentation: networking: Update the phy_port infrastructure description

["Christophe Leroy (CS GROUP)" <chleroy@kernel.org>]

Le 27/09/2026 à 15:36, Maxime Chevallier a écrit :
> With SFP now properly supported with phy_port, add some details in the
> documentation. Fix a typo along the way (driver -> driven).
> 
> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
> Tested-by: Aleksei Sviridkin <f@lex.la>
> Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>

Reviewed-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>

> ---
>   Documentation/networking/phy-port.rst | 26 +++++++++++++++++++++-----
>   1 file changed, 21 insertions(+), 5 deletions(-)
> 
> diff --git a/Documentation/networking/phy-port.rst b/Documentation/networking/phy-port.rst
> index 6e28d9094bce..2a9b1ec93b70 100644
> --- a/Documentation/networking/phy-port.rst
> +++ b/Documentation/networking/phy-port.rst
> @@ -99,13 +99,29 @@ will eventually be able to report its own ksettings::
>               (_____)-----| Port |
>                           +------+
>   
> +SFP ports
> +=========
> +
> +SFP interfaces involve 2 distinct components, each represented by
> +a :c:type:`struct phy_port <phy_port>` instance :
> +
> + - The SFP cage itself is a :c:type:`struct phy_port <phy_port>`. It's special
> +   in that it's not an MDI interface, but rather a hot-pluggable MII.
> +   The :c:type:`struct phy_port <phy_port>` associated to it lists the different
> +   MII interfaces we can use on the cage.
> +
> + - The SFP module, when inserted, will also be associated to a
> +   :c:type:`struct phy_port <phy_port>`, that represents the various linkmodes
> +   that it gives access to. The module's :c:type:`struct phy_port <phy_port>`
> +   doesn't supersede the cage's port, it references it through
> +   the :c:type:`struct phy_port <phy_port>` :c:member:`upstream_port` field.
> +
>   Next steps
>   ==========
>   
> -As of writing this documentation, only ports controlled by PHY devices are
> -supported. The next steps will be to add the Netlink API to expose these
> -to userspace and add support for raw ports (controlled by some firmware, and directly
> -managed by the NIC driver).
> +As of writing this documentation, the port's presence and information can only
> +be queried, and it's not possible to change any of the port's settings or select
> +which one should be used.
>   
>   Another parallel task is the introduction of a MII muxing framework to allow the
> -control of non-PHY driver multi-port setups.
> +control of non-PHY driven multi-port setups.