All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH net-next v7 00/15] net: phy: Introduce PHY ports representation
@ 2025-06-30 14:32 Maxime Chevallier
  2025-06-30 14:33 ` [PATCH net-next v7 01/15] dt-bindings: net: Introduce the ethernet-connector description Maxime Chevallier
                   ` (14 more replies)
  0 siblings, 15 replies; 22+ messages in thread
From: Maxime Chevallier @ 2025-06-30 14:32 UTC (permalink / raw)
  To: davem
  Cc: Maxime Chevallier, netdev, linux-kernel, linux-arm-msm,
	thomas.petazzoni, Andrew Lunn, Jakub Kicinski, Eric Dumazet,
	Paolo Abeni, Russell King, linux-arm-kernel, Christophe Leroy,
	Herve Codina, Florian Fainelli, Heiner Kallweit, Vladimir Oltean,
	Köry Maincent, Marek Behún, Oleksij Rempel,
	Nicolò Veronese, Simon Horman, mwojtas, Antoine Tenart,
	devicetree, Conor Dooley, Krzysztof Kozlowski, Rob Herring,
	Romain Gantois, Daniel Golle, Dimitri Fedrau

Hi everyone,

Here's a V7 for the ongoing support for Ethernet media-side port
support.

This V7 addresses some of the shortcomings, including :
 - A rework of the way we assign each port's supported field
 - The support for combo-ports on the marvell 88x3310
 - Patch 2 is back, it was removed after Russell's comments in RFCV2.

At that time, Russell said :

" > Mark BaseT as being a 4-lanes mode.

This is a problem:

1.4.50 10BASE-T: IEEE 802.3 Physical Layer specification for a 10 Mb/s
CSMA/CD local area network over two pairs of twisted-pair telephone
wire. (See IEEE Std 802.3, Clause 14.)

Then we have the 100BASE-T* family, which can be T1, T2, T4 or TX.
T1 is over a single balanced twisted pair. T2 is over two pairs of
Cat 3 or better. T4 is over four pairs of Cat3/4/5.

The common 100BASE-T* type is TX, which is over two pairs of Cat5.
This is sadly what the ethtool 100baseT link modes are used to refer
to.

We do have a separate link mode for 100baseT1, but not 100baseT4.

So, these ethtool modes that are of the form baseT so far are
describing generally two pairs, one pair in each direction. (T1 is
a single pair that is bidirectional.)

It's only once we get to 1000BASE-T (1000baseT) that we get to an
ethtool link mode that has four lanes in a bidirectional fashion.

So, simply redefining this ends up changing 10baseT and 100baseT from
a single lane in each direction to four lanes (and is a "lane" here
defined as the total number of pairs used for communication in both
directions, or the total number of lanes used in either direction.

Hence, I'm not sure this makes sense."

Russell it completely right, and I failed to make my point at that time.
Now, I think this patch does make sense as :
 - We treat BaseT1 as its own medium
 - In patch 3, we enforce the following :
   - 10 and 100BaseT work on 2 pairs, but can also work on a 4-pair port
   - 1000BaseT and above need 4 pairs

I'm again open for any kind of discussion :)

Before going into the details, a few important notes :

 - This is only a first phase. It instantiates the port, and leverage
   that to make the MAC <-> PHY <-> SFP usecase simpler.

 - Next phase will deal with controlling the port state, as well as the
   netlink uAPI for that.

 - The end-goal is to enable support for complex port MUX. This
   preliminary work focuses on PHY-driven ports, but this will be
   extended to support muxing at the MII level (Multi-phy, or compo PHY
   + SFP as found on Turris Omnia for example).

 - The naming is definitely not set in stone. I named that "phy_port",
   but this may convey the false sense that this is phylib-specific.
   Even the word "port" is not that great, as it already has several
   different meanings in the net world (switch port, devlink port,
   etc.). I used the term "connector" in the binding.

A bit of history on that work :

The end goal that I personnaly want to achieve is :

            + PHY - RJ45
            | 
 MAC - MUX -+ PHY - RJ45

After many discussions here on netdev@, but also at netdevconf[1] and
LPC[2], there appears to be several analoguous designs that exist out
there.

[1] : https://netdevconf.info/0x17/sessions/talk/improving-multi-phy-and-multi-port-interfaces.html
[2] : https://lpc.events/event/18/contributions/1964/ (video isn't the
right one)

Take the MAchiatobin, it has 2 interfaces that looks like this :

 MAC - PHY -+ RJ45
            |
	    + SFP - Whatever the module does

Now, looking at the Turris Omnia, we have :


 MAC - MUX -+ PHY - RJ45
            |
	    + SFP - Whatever the module does

We can find more example of this kind of designs, the common part is
that we expose multiple front-facing media ports. This is what this
current work aims at supporting. As of right now, it does'nt add any
support for muxing, but this will come later on.

This first phase focuses on phy-driven ports only, but there are already
quite some challenges already. For one, we can't really autodetect how
many ports are sitting behind a PHY. That's why this series introduces a
new binding. Describing ports in DT should however be a last-resort
thing when we need to clear some ambiguity about the PHY media-side.

The only use-cases that we have today for multi-port PHYs are combo PHYs
that drive both a Copper port and an SFP (the Macchiatobin case). This
in itself is challenging and this series only addresses part of this
support, by registering a phy_port for the PHY <-> SFP connection. The
SFP module should in the end be considered as a port as well, but that's
not yet the case.

However, because now PHYs can register phy_ports for every media-side
interface they have, they can register the capabilities of their ports,
which allows making the PHY-driver SFP case much more generic.

Let me know what you think, I'm all in for discussions :)

Regards,

Changes in V7:
 - Move ethtool_medium_get_supported to phy_caps
 - support combo-ports, each with a given set of supported modes
 - Introduce the notion of 'not-described' ports

Changes in V6:

 - Fixed kdoc on patch 3
 - Addressed a missing port-ops registration for the Marvell 88x2222
   driver
 - Addressed a warning reported by Simon on the DP83822 when building
   without CONFIG_OF_MDIO

Changes in V5 :

 - renamed the bindings to use the term "connector" instead of "port"
 - Rebased, and fixed some issues reported on the 83822 driver
 - Use phy_caps

Changes in V4 :

 - Introduced a kernel doc
 - Reworked the mediums definitions in patch 2
 - QCA807x now uses the generic SFP support
 - Fixed some implementation bugs to build the support list based on the
   interfaces supported on a port

V6: https://lore.kernel.org/netdev/20250507135331.76021-1-maxime.chevallier@bootlin.com/
V5: https://lore.kernel.org/netdev/20250425141511.182537-1-maxime.chevallier@bootlin.com/
V4: https://lore.kernel.org/netdev/20250213101606.1154014-1-maxime.chevallier@bootlin.com/
V3: https://lore.kernel.org/netdev/20250207223634.600218-1-maxime.chevallier@bootlin.com/
RFC V2: https://lore.kernel.org/netdev/20250122174252.82730-1-maxime.chevallier@bootlin.com/
RFC V1: https://lore.kernel.org/netdev/20241220201506.2791940-1-maxime.chevallier@bootlin.com/

Maxime

Maxime Chevallier (15):
  dt-bindings: net: Introduce the ethernet-connector description
  net: ethtool: common: Indicate that BaseT works on up to 4 lanes
  net: ethtool: Introduce ETHTOOL_LINK_MEDIUM_* values
  net: phy: Introduce PHY ports representation
  net: phy: dp83822: Add support for phy_port representation
  net: phy: Create a phy_port for PHY-driven SFPs
  net: phy: Introduce generic SFP handling for PHY drivers
  net: phy: marvell-88x2222: Support SFP through phy_port interface
  net: phy: marvell: Support SFP through phy_port interface
  net: phy: marvell10g: Support SFP through phy_port
  net: phy: at803x: Support SFP through phy_port interface
  net: phy: qca807x: Support SFP through phy_port interface
  net: phy: Only rely on phy_port for PHY-driven SFP
  net: phy: dp83822: Add SFP support through the phy_port interface
  Documentation: networking: Document the phy_port infrastructure

 .../bindings/net/ethernet-connector.yaml      |  47 +++
 .../devicetree/bindings/net/ethernet-phy.yaml |  18 +
 Documentation/networking/index.rst            |   1 +
 Documentation/networking/phy-port.rst         | 111 ++++++
 MAINTAINERS                                   |   3 +
 drivers/net/phy/Makefile                      |   2 +-
 drivers/net/phy/dp83822.c                     |  78 +++--
 drivers/net/phy/marvell-88x2222.c             |  98 +++---
 drivers/net/phy/marvell.c                     | 100 +++---
 drivers/net/phy/marvell10g.c                  |  47 +--
 drivers/net/phy/phy-caps.h                    |   5 +
 drivers/net/phy/phy_caps.c                    |  58 ++++
 drivers/net/phy/phy_device.c                  | 327 +++++++++++++++++-
 drivers/net/phy/phy_port.c                    | 173 +++++++++
 drivers/net/phy/qcom/at803x.c                 |  64 +---
 drivers/net/phy/qcom/qca807x.c                |  75 ++--
 include/linux/ethtool.h                       |  44 ++-
 include/linux/phy.h                           |  38 +-
 include/linux/phy_port.h                      |  97 ++++++
 include/uapi/linux/ethtool.h                  |  20 ++
 net/ethtool/common.c                          | 267 ++++++++------
 21 files changed, 1284 insertions(+), 389 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/net/ethernet-connector.yaml
 create mode 100644 Documentation/networking/phy-port.rst
 create mode 100644 drivers/net/phy/phy_port.c
 create mode 100644 include/linux/phy_port.h

-- 
2.49.0



^ permalink raw reply	[flat|nested] 22+ messages in thread
* Re: [PATCH net-next v7 04/15] net: phy: Introduce PHY ports representation
@ 2025-07-06 10:50 kernel test robot
  0 siblings, 0 replies; 22+ messages in thread
From: kernel test robot @ 2025-07-06 10:50 UTC (permalink / raw)
  To: oe-kbuild; +Cc: lkp, Dan Carpenter

BCC: lkp@intel.com
CC: oe-kbuild-all@lists.linux.dev
In-Reply-To: <20250630143315.250879-5-maxime.chevallier@bootlin.com>
References: <20250630143315.250879-5-maxime.chevallier@bootlin.com>
TO: Maxime Chevallier <maxime.chevallier@bootlin.com>
TO: davem@davemloft.net
CC: Maxime Chevallier <maxime.chevallier@bootlin.com>
CC: netdev@vger.kernel.org
CC: linux-kernel@vger.kernel.org
CC: linux-arm-msm@vger.kernel.org
CC: thomas.petazzoni@bootlin.com
CC: Andrew Lunn <andrew@lunn.ch>
CC: Jakub Kicinski <kuba@kernel.org>
CC: Eric Dumazet <edumazet@google.com>
CC: Paolo Abeni <pabeni@redhat.com>
CC: Russell King <linux@armlinux.org.uk>
CC: linux-arm-kernel@lists.infradead.org
CC: Christophe Leroy <christophe.leroy@csgroup.eu>
CC: Herve Codina <herve.codina@bootlin.com>
CC: Florian Fainelli <f.fainelli@gmail.com>
CC: Heiner Kallweit <hkallweit1@gmail.com>
CC: Vladimir Oltean <vladimir.oltean@nxp.com>
CC: "Köry Maincent" <kory.maincent@bootlin.com>
CC: "Marek Behún" <kabel@kernel.org>
CC: Oleksij Rempel <o.rempel@pengutronix.de>
CC: "Nicolò Veronese" <nicveronese@gmail.com>
CC: Simon Horman <horms@kernel.org>
CC: mwojtas@chromium.org
CC: Antoine Tenart <atenart@kernel.org>
CC: devicetree@vger.kernel.org
CC: Conor Dooley <conor+dt@kernel.org>
CC: Krzysztof Kozlowski <krzk@kernel.org>
CC: Rob Herring <robh@kernel.org>
CC: Romain Gantois <romain.gantois@bootlin.com>
CC: Daniel Golle <daniel@makrotopia.org>

Hi Maxime,

kernel test robot noticed the following build warnings:

[auto build test WARNING on net-next/main]

url:    https://github.com/intel-lab-lkp/linux/commits/Maxime-Chevallier/dt-bindings-net-Introduce-the-ethernet-connector-description/20250630-224035
base:   net-next/main
patch link:    https://lore.kernel.org/r/20250630143315.250879-5-maxime.chevallier%40bootlin.com
patch subject: [PATCH net-next v7 04/15] net: phy: Introduce PHY ports representation
:::::: branch date: 6 days ago
:::::: commit date: 6 days ago
config: x86_64-randconfig-r071-20250706 (https://download.01.org/0day-ci/archive/20250706/202507061812.0aBYBa9l-lkp@intel.com/config)
compiler: gcc-12 (Debian 12.2.0-14+deb12u1) 12.2.0

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Reported-by: Dan Carpenter <error27@gmail.com>
| Closes: https://lore.kernel.org/r/202507061812.0aBYBa9l-lkp@intel.com/

smatch warnings:
drivers/net/phy/phy_port.c:130 phy_port_get_type() warn: bitwise AND condition is false here

vim +130 drivers/net/phy/phy_port.c

055cbf51317b1e Maxime Chevallier 2025-06-30  121  
055cbf51317b1e Maxime Chevallier 2025-06-30  122  /**
055cbf51317b1e Maxime Chevallier 2025-06-30  123   * phy_port_get_type() - get the PORT_* attribut for that port.
055cbf51317b1e Maxime Chevallier 2025-06-30  124   * @port: The port we want the information from
055cbf51317b1e Maxime Chevallier 2025-06-30  125   *
055cbf51317b1e Maxime Chevallier 2025-06-30  126   * Returns: A PORT_XXX value.
055cbf51317b1e Maxime Chevallier 2025-06-30  127   */
055cbf51317b1e Maxime Chevallier 2025-06-30  128  int phy_port_get_type(struct phy_port *port)
055cbf51317b1e Maxime Chevallier 2025-06-30  129  {
055cbf51317b1e Maxime Chevallier 2025-06-30 @130  	if (port->mediums & ETHTOOL_LINK_MEDIUM_BASET)

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

^ permalink raw reply	[flat|nested] 22+ messages in thread

end of thread, other threads:[~2025-07-14 19:11 UTC | newest]

Thread overview: 22+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-06-30 14:32 [PATCH net-next v7 00/15] net: phy: Introduce PHY ports representation Maxime Chevallier
2025-06-30 14:33 ` [PATCH net-next v7 01/15] dt-bindings: net: Introduce the ethernet-connector description Maxime Chevallier
2025-07-08 15:57   ` Rob Herring
2025-07-09  6:36     ` Maxime Chevallier
2025-06-30 14:33 ` [PATCH net-next v7 02/15] net: ethtool: common: Indicate that BaseT works on up to 4 lanes Maxime Chevallier
2025-06-30 14:33 ` [PATCH net-next v7 03/15] net: ethtool: Introduce ETHTOOL_LINK_MEDIUM_* values Maxime Chevallier
2025-06-30 14:33 ` [PATCH net-next v7 04/15] net: phy: Introduce PHY ports representation Maxime Chevallier
2025-07-01 13:02   ` Simon Horman
2025-07-01 13:06     ` Maxime Chevallier
2025-07-14 19:08   ` Dan Carpenter
2025-06-30 14:33 ` [PATCH net-next v7 05/15] net: phy: dp83822: Add support for phy_port representation Maxime Chevallier
2025-06-30 14:33 ` [PATCH net-next v7 06/15] net: phy: Create a phy_port for PHY-driven SFPs Maxime Chevallier
2025-06-30 14:33 ` [PATCH net-next v7 07/15] net: phy: Introduce generic SFP handling for PHY drivers Maxime Chevallier
2025-06-30 14:33 ` [PATCH net-next v7 08/15] net: phy: marvell-88x2222: Support SFP through phy_port interface Maxime Chevallier
2025-06-30 14:33 ` [PATCH net-next v7 09/15] net: phy: marvell: " Maxime Chevallier
2025-06-30 14:33 ` [PATCH net-next v7 10/15] net: phy: marvell10g: Support SFP through phy_port Maxime Chevallier
2025-06-30 14:33 ` [PATCH net-next v7 11/15] net: phy: at803x: Support SFP through phy_port interface Maxime Chevallier
2025-06-30 14:33 ` [PATCH net-next v7 12/15] net: phy: qca807x: " Maxime Chevallier
2025-06-30 14:33 ` [PATCH net-next v7 13/15] net: phy: Only rely on phy_port for PHY-driven SFP Maxime Chevallier
2025-06-30 14:33 ` [PATCH net-next v7 14/15] net: phy: dp83822: Add SFP support through the phy_port interface Maxime Chevallier
2025-06-30 14:33 ` [PATCH net-next v7 15/15] Documentation: networking: Document the phy_port infrastructure Maxime Chevallier
  -- strict thread matches above, loose matches on Subject: below --
2025-07-06 10:50 [PATCH net-next v7 04/15] net: phy: Introduce PHY ports representation kernel test robot

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.