Revert "Introduce PHY listing and link_topology tracking"

This reverts commit 32bb4515e34469975abc936deb0a116c4a445817.
This reverts commit d078d480639a4f3b5fc2d56247afa38e0956483a.
This reverts commit fcc4b105caa4b844bf043375bf799c20a9c99db1.
This reverts commit 345237dbc1bdbb274c9fb9ec38976261ff4a40b8.
This reverts commit 7db69ec9cfb8b4ab50420262631fb2d1908b25bf.
This reverts commit 95132a018f00f5dad38bdcfd4180d1af955d46f6.
This reverts commit 63d5eaf35ac36cad00cfb3809d794ef0078c822b.
This reverts commit c29451aefcb42359905d18678de38e52eccb3bb5.
This reverts commit 2ab0edb505faa9ac90dee1732571390f074e8113.
This reverts commit dedd702a35793ab462fce4c737eeba0badf9718e.
This reverts commit 034fcc210349b873ece7356905be5c6ca11eef2a.
This reverts commit 9c5625f559ad6fe9f6f733c11475bf470e637d34.
This reverts commit 02018c544ef113e980a2349eba89003d6f399d22.

Looks like we need more time for reviews, and incremental
changes will be hard to make sense of. So revert.

Link: https://lore.kernel.org/all/ZZP6FV5sXEf+xd58@shell.armlinux.org.uk/
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

3 files changed, 0 insertions, 173 deletions

diff --git a/Documentation/networking/ethtool-netlink.rst b/Documentation/networking/ethtool-netlink.rst
index 97ff787a7dd8..d583d9abf2f8 100644
--- a/Documentation/networking/ethtool-netlink.rst
+++ b/Documentation/networking/ethtool-netlink.rst
@@ -57,7 +57,6 @@ Structure of this header is
   ``ETHTOOL_A_HEADER_DEV_INDEX``  u32     device ifindex
   ``ETHTOOL_A_HEADER_DEV_NAME``   string  device name
   ``ETHTOOL_A_HEADER_FLAGS``      u32     flags common for all requests
-  ``ETHTOOL_A_HEADER_PHY_INDEX``  u32     phy device index
   ==============================  ======  =============================
 
 ``ETHTOOL_A_HEADER_DEV_INDEX`` and ``ETHTOOL_A_HEADER_DEV_NAME`` identify the
@@ -82,12 +81,6 @@ the behaviour is backward compatible, i.e. requests from old clients not aware
 of the flag should be interpreted the way the client expects. A client must
 not set flags it does not understand.
 
-``ETHTOOL_A_HEADER_PHY_INDEX`` identify the ethernet PHY the message relates to.
-As there are numerous commands that are related to PHY configuration, and because
-we can have more than one PHY on the link, the PHY index can be passed in the
-request for the commands that needs it. It is however not mandatory, and if it
-is not passed for commands that target a PHY, the net_device.phydev pointer
-is used, as a fallback that keeps the legacy behaviour.
 
 Bit sets
 ========
@@ -2011,49 +2004,6 @@ The attributes are propagated to the driver through the following structure:
 .. kernel-doc:: include/linux/ethtool.h
     :identifiers: ethtool_mm_cfg
 
-PHY_GET
-=======
-
-Retrieve information about a given Ethernet PHY sitting on the link. As there
-can be more than one PHY, the DUMP operation can be used to list the PHYs
-present on a given interface, by passing an interface index or name in
-the dump request
-
-Request contents:
-
-  ====================================  ======  ==========================
-  ``ETHTOOL_A_PHY_HEADER``              nested  request header
-  ====================================  ======  ==========================
-
-Kernel response contents:
-
-  ===================================== ======  ==========================
-  ``ETHTOOL_A_PHY_HEADER``              nested  request header
-  ``ETHTOOL_A_PHY_INDEX``               u32     the phy's unique index, that can
-                                                be used for phy-specific requests
-  ``ETHTOOL_A_PHY_DRVNAME``             string  the phy driver name
-  ``ETHTOOL_A_PHY_NAME``                string  the phy device name
-  ``ETHTOOL_A_PHY_UPSTREAM_TYPE``       u32     the type of device this phy is
-                                                connected to
-  ``ETHTOOL_A_PHY_UPSTREAM_PHY``        nested  if the phy is connected to another
-                                                phy, this nest contains info on
-                                                that connection
-  ``ETHTOOL_A_PHY_DOWNSTREAM_SFP_NAME`` string  if the phy controls an sfp bus,
-                                                the name of the sfp bus
-  ``ETHTOOL_A_PHY_ID``                  u32     the phy id if the phy is C22
-  ===================================== ======  ==========================
-
-When ``ETHTOOL_A_PHY_UPSTREAM_TYPE`` is PHY_UPSTREAM_PHY, the PHY's parent is
-another PHY. Information on the parent PHY will be set in the
-``ETHTOOL_A_PHY_UPSTREAM_PHY`` nest, which has the following structure :
-
-  =================================== ======  ==========================
-  ``ETHTOOL_A_PHY_UPSTREAM_INDEX``    u32     the PHY index of the upstream PHY
-  ``ETHTOOL_A_PHY_UPSTREAM_SFP_NAME`` string  if this PHY is connected to it's
-                                                parent PHY through an SFP bus, the
-                                                name of this sfp bus
-  =================================== ======  ==========================
-
 Request translation
 ===================
 
@@ -2160,5 +2110,4 @@ are netlink only.
   n/a                                 ``ETHTOOL_MSG_PLCA_GET_STATUS``
   n/a                                 ``ETHTOOL_MSG_MM_GET``
   n/a                                 ``ETHTOOL_MSG_MM_SET``
-  n/a                                 ``ETHTOOL_MSG_PHY_GET``
   =================================== =====================================
diff --git a/Documentation/networking/index.rst b/Documentation/networking/index.rst
index a2c45a75a4a6..69f3d6dcd9fd 100644
--- a/Documentation/networking/index.rst
+++ b/Documentation/networking/index.rst
@@ -88,7 +88,6 @@ Contents:
    operstates
    packet_mmap
    phonet
-   phy-link-topology
    pktgen
    plip
    ppp_generic
diff --git a/Documentation/networking/phy-link-topology.rst b/Documentation/networking/phy-link-topology.rst
deleted file mode 100644
index 1fd8e904ef4b..000000000000
--- a/Documentation/networking/phy-link-topology.rst
+++ /dev/null
@@ -1,121 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-=================
-PHY link topology
-=================
-
-Overview
-========
-
-The PHY link topology representation in the networking stack aims at representing
-the hardware layout for any given Ethernet link.
-
-An Ethernet Interface from userspace's point of view is nothing but a
-:c:type:`struct net_device <net_device>`, which exposes configuration options
-through the legacy ioctls and the ethool netlink commands. The base assumption
-when designing these configuration channels were that the link looked
-something like 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).
-
-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 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
-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) |
-  +-----+         +-----------------------+         +--------------+
-
-This is where the model of having a single net_device.phydev pointer shows its
-limitations, as we now have 2 PHYs on the link.
-
-The phy_link topology framework aims at providing a way to keep track of every
-PHY on the link, for use by both kernel drivers and subsystems, but also to
-report the topology to userspace, allowing to target individual PHYs in configuration
-commands.
-
-API
-===
-
-The :c:type:`struct phy_link_topology <phy_link_topology>` is a per-netdevice
-resource, that gets initialized at netdevice creation. Once it's initialized,
-it is then possible to register PHYs to the topology through :
-
-:c:func:`phy_link_topo_add_phy`
-
-Besides registering the PHY to the topology, this call will also assign a unique
-index to the PHY, which can then be reported to userspace to refer to this PHY
-(akin to the ifindex). This index is a u32, ranging from 1 to U32_MAX. The value
-0 is reserved to indicate the PHY doesn't belong to any topology yet.
-
-The PHY can then be removed from the topology through
-
-:c:func:`phy_link_topo_del_phy`
-
-These function are already hooked into the phylib subsystem, so all PHYs that
-are linked to a net_device through :c:func:`phy_attach_direct` will automatically
-join the netdev's topology.
-
-PHYs that are on a SFP module will also be automatically registered IF the SFP
-upstream is phylink (so, no media-converter).
-
-PHY drivers that can be used as SFP upstream need to call :c:func:`phy_sfp_attach_phy`
-and :c:func:`phy_sfp_detach_phy`, which can be used as a
-.attach_phy / .detach_phy implementation for the
-:c:type:`struct sfp_upstream_ops <sfp_upstream_ops>`.
-
-UAPI
-====
-
-There exist a set of netlink commands to query the link topology from userspace,
-see ``Documentation/networking/ethtool-netlink.rst``.
-
-The whole point of having a topology representation is to assign the phyindex
-field in :c:type:`struct phy_device <phy_device>`. This index is reported to
-userspace using the ``ETHTOOL_MSG_PHY_GET`` ethtnl command. Performing a DUMP operation
-will result in all PHYs from all net_device being listed. The DUMP command
-accepts either a ``ETHTOOL_A_HEADER_DEV_INDEX`` or ``ETHTOOL_A_HEADER_DEV_NAME``
-to be passed in the request to filter the DUMP to a single net_device.
-
-The retrieved index can then be passed as a request parameter using the
-``ETHTOOL_A_HEADER_PHY_INDEX`` field in the following ethnl commands :
-
-* ``ETHTOOL_MSG_STRSET_GET`` to get the stats string set from a given PHY
-* ``ETHTOOL_MSG_CABLE_TEST_ACT`` and ``ETHTOOL_MSG_CABLE_TEST_ACT``, to perform
-  cable testing on a given PHY on the link (most likely the outermost PHY)
-* ``ETHTOOL_MSG_PSE_SET`` and ``ETHTOOL_MSG_PSE_GET`` for PHY-controlled PoE and PSE settings
-* ``ETHTOOL_MSG_PLCA_GET_CFG``, ``ETHTOOL_MSG_PLCA_SET_CFG`` and ``ETHTOOL_MSG_PLCA_GET_STATUS``
-  to set the PLCA (Physical Layer Collision Avoidance) parameters
-
-Note that the PHY index can be passed to other requests, which will silently
-ignore it if present and irrelevant.