With SFP now properly supported with phy_port, add some details in the documentation. Fix a typo along the way (driver -> driven). Signed-off-by: Maxime Chevallier --- 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..73ea06db0fd9 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 ` instance : + + - The SFP cage itself is a :c:type:`struct 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 ` 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 `, that represents the various linkmodes + that it gives access to. The module's :c:type:`struct phy_port ` + doesn't supersedes the cage's port, it references it through + the :c:type:`struct 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. -- 2.54.0