Hi everyone,

This is v19 of the phy_port work. Patches 2 and 3 lack PHY maintainers reviews.

This v19 has no changes compared to v18, but patch 2 was rebased on top
of the recent 1.6T linkmodes.

Thanks for everyone's patience and reviews on that work ! Now, the
usual blurb for the series description.

As a remainder, 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 v19:
 - Rebase on net-next, add the 4 new 1600G linkmodes

Changes in v18:
 - Added a missing 'static' when declaring the medium names.

Changes in v17:
 - Moved the medium names to patch 3
 - Moved some mediums helpers out of uapi, and the logic into
   net/ethtool/common.c instead of inline functions in headers
 - Added a MAINTAINERS entry
 - Aggregated reviews/tests
 - Rebased on net-next

Changes in v16:
 - From Andrew, relaxed the check on the number of pairs so that we only
   fail when baseT is missing pairs
 - Add a check for either 1, 2 or 4 pairs
 - Lots of typos (mostly lanes -> pairs)
 - Added Andrew's review tags (thanks again)
 - From Rob, added an "else" statement in the ethernet-connector binding
 - Changed the node name for ethernet connectors to be decimal

Changes in V15:
 - Update bindings, docs and code to use pairs instead of lanes
 - Make pairs only relevant for BaseT

Changes in V14:
 - Fixed kdoc
 - Use the sfp module_caps feature.

Changes in V13:
 - Added phy_caps support for interface selection
 - Aggregated tested-by tags

Changes in V12:
 - Moved some of phylink's internal helpers to phy_caps for reuse in
   phylib
 - Fixed SFP interface selection
 - Added Rob's review and changes in patch 6

Changes in V11:
 - The ti,fiber-mode property was deprecated in favor of the
   ethernet-connector binding
 - The .attach_port was split into an MDI and an MII version
 - I added the warning back in the AR8031 PHY driver
 - There is now an init-time check on the number of lanes associated to
   every linkmode, making sure the number of lanes is above or equal to
   the minimum required
 - Various typos were fixed all around
 - We no longer use sfp_select_interface() for SFP interface validation

Changes in V10:
 - Rebase on net-next
 - Fix a typo reported by Köry
 - Aggregate all reviews
 - Fix the conflict on the qcom driver

Changes in V9:
 - Removed maxItems and items from the connector binding
 - Fixed a typo in the binding

Changes in V8:
 - Added maxItems on the connector media binding
 - Made sure we parse a single medium
 - Added a missing bitwise macro

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

V18: https://lore.kernel.org/r/20251120205508.553909-1-maxime.chevallier@bootlin.com
V17: https://lore.kernel.org/all/20251119195920.442860-1-maxime.chevallier@bootlin.com/
V16: https://lore.kernel.org/all/20251113081418.180557-2-maxime.chevallier@bootlin.com/
V15: https://lore.kernel.org/all/20251106094742.2104099-1-maxime.chevallier@bootlin.com/
V14: https://lore.kernel.org/netdev/20251013143146.364919-1-maxime.chevallier@bootlin.com/
V13: https://lore.kernel.org/netdev/20250921160419.333427-1-maxime.chevallier@bootlin.com/
V12: https://lore.kernel.org/netdev/20250909152617.119554-1-maxime.chevallier@bootlin.com/
V11: https://lore.kernel.org/netdev/20250814135832.174911-1-maxime.chevallier@bootlin.com/
V10: https://lore.kernel.org/netdev/20250722121623.609732-1-maxime.chevallier@bootlin.com/
V9: https://lore.kernel.org/netdev/20250717073020.154010-1-maxime.chevallier@bootlin.com/
V8: https://lore.kernel.org/netdev/20250710134533.596123-1-maxime.chevallier@bootlin.com/
v7: https://lore.kernel.org/netdev/20250630143315.250879-1-maxime.chevallier@bootlin.com/
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: Introduce ETHTOOL_LINK_MEDIUM_* values
  net: phy: Introduce PHY ports representation
  net: phy: dp83822: Add support for phy_port representation
  dt-bindings: net: dp83822: Deprecate ti,fiber-mode
  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



Maxime Chevallier (15):
  dt-bindings: net: Introduce the ethernet-connector description
  net: ethtool: Introduce ETHTOOL_LINK_MEDIUM_* values
  net: phy: Introduce PHY ports representation
  net: phy: dp83822: Add support for phy_port representation
  dt-bindings: net: dp83822: Deprecate ti,fiber-mode
  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      |  57 +++
 .../devicetree/bindings/net/ethernet-phy.yaml |  18 +
 .../devicetree/bindings/net/ti,dp83822.yaml   |   9 +-
 Documentation/networking/index.rst            |   1 +
 Documentation/networking/phy-port.rst         | 111 ++++++
 MAINTAINERS                                   |  10 +
 drivers/net/phy/Makefile                      |   2 +-
 drivers/net/phy/dp83822.c                     |  78 ++--
 drivers/net/phy/marvell-88x2222.c             |  94 ++---
 drivers/net/phy/marvell.c                     |  92 ++---
 drivers/net/phy/marvell10g.c                  |  52 +--
 drivers/net/phy/phy-caps.h                    |   5 +
 drivers/net/phy/phy-core.c                    |   6 +
 drivers/net/phy/phy_caps.c                    |  65 ++++
 drivers/net/phy/phy_device.c                  | 337 +++++++++++++++++-
 drivers/net/phy/phy_port.c                    | 212 +++++++++++
 drivers/net/phy/qcom/at803x.c                 |  77 ++--
 drivers/net/phy/qcom/qca807x.c                |  72 ++--
 include/linux/ethtool.h                       |  36 +-
 include/linux/phy.h                           |  63 +++-
 include/linux/phy_port.h                      |  99 +++++
 net/ethtool/common.c                          | 287 +++++++++------
 22 files changed, 1398 insertions(+), 385 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

On Sat, 22 Nov 2025 13:42:59 +0100 Maxime Chevallier wrote:
> This is v19 of the phy_port work. Patches 2 and 3 lack PHY maintainers reviews.
> 
> This v19 has no changes compared to v18, but patch 2 was rebased on top
> of the recent 1.6T linkmodes.
> 
> Thanks for everyone's patience and reviews on that work ! Now, the
> usual blurb for the series description.

Hopefully we can still make v6.19, but we hooked up Claude Code review
to patchwork this week, and it points out some legit issues here :(
Some look transient but others are definitely legit, please look thru
this:

https://netdev-ai.bots.linux.dev/ai-review.html?id=5388d317-98c9-458e-8655-d60f31112574
-- 
pw-bot: cr

Hi Chris,

On 27/11/2025 04:00, Jakub Kicinski wrote:
> On Sat, 22 Nov 2025 13:42:59 +0100 Maxime Chevallier wrote:
>> This is v19 of the phy_port work. Patches 2 and 3 lack PHY maintainers reviews.
>>
>> This v19 has no changes compared to v18, but patch 2 was rebased on top
>> of the recent 1.6T linkmodes.
>>
>> Thanks for everyone's patience and reviews on that work ! Now, the
>> usual blurb for the series description.
> 
> Hopefully we can still make v6.19, but we hooked up Claude Code review
> to patchwork this week, and it points out some legit issues here :(
> Some look transient but others are definitely legit, please look thru
> this:
> 
> https://netdev-ai.bots.linux.dev/ai-review.html?id=5388d317-98c9-458e-8655-d60f31112574

I was told by Paolo to reach out with any feedback on the LLM reviews :

First, I find the whole thing pretty accurate in the reviews, congrats.

I did find one review that's not totally accurate :

https://netdev-ai.bots.linux.dev/ai-review.html?id=5388d317-98c9-458e-8655-d60f31112574#patch-7

Extract from the comment :


--------x8----------------------------------------------------------------------

> @@ -473,89 +473,70 @@ static int mv2222_config_init(struct phy_device *phydev)
>  	return 0;
>  }
>
> -static int mv2222_sfp_insert(void *upstream, const struct sfp_eeprom_id *id)
> +static int mv2222_configure_serdes(struct phy_port *port, bool enable,
> +				   phy_interface_t interface)
>  {
> -	struct phy_device *phydev = upstream;
> -	const struct sfp_module_caps *caps;
> -	phy_interface_t sfp_interface;
> +	struct phy_device *phydev = port_phydev(port);
>  	struct mv2222_data *priv;
> -	struct device *dev;
> -	int ret;
> +	int ret = 0;
>
>  	priv = phydev->priv;
> -	dev = &phydev->mdio.dev;
> -
> -	caps = sfp_get_module_caps(phydev->sfp_bus);
> -
> -	phydev->port = caps->port;
> -	sfp_interface = sfp_select_interface(phydev->sfp_bus, caps->link_modes);
> -
> -	dev_info(dev, "%s SFP module inserted\n", phy_modes(sfp_interface));
> +	priv->line_interface = interface;
>
> -	if (sfp_interface != PHY_INTERFACE_MODE_10GBASER &&
> -	    sfp_interface != PHY_INTERFACE_MODE_1000BASEX &&
> -	    sfp_interface != PHY_INTERFACE_MODE_SGMII) {
> -		dev_err(dev, "Incompatible SFP module inserted\n");
> +	if (enable) {
> +		linkmode_and(priv->supported, phydev->supported, port->supported);
>
> -		return -EINVAL;
> -	}
> -
> -	priv->line_interface = sfp_interface;
> -	linkmode_and(priv->supported, phydev->supported, caps->link_modes);
> +		ret = mv2222_config_line(phydev);
> +		if (ret < 0)
> +			return ret;
>
> -	ret = mv2222_config_line(phydev);
> -	if (ret < 0)
> -		return ret;
> +		if (mutex_trylock(&phydev->lock)) {
> +			ret = mv2222_config_aneg(phydev);
> +			mutex_unlock(&phydev->lock);
> +		}
>
> -	if (mutex_trylock(&phydev->lock)) {
> -		ret = mv2222_config_aneg(phydev);
> -		mutex_unlock(&phydev->lock);
> +	} else {
> +		linkmode_zero(priv->supported);
>  	}
>
>  	return ret;
>  }
>
> -static void mv2222_sfp_remove(void *upstream)
> -{
> -	struct phy_device *phydev = upstream;
> -	struct mv2222_data *priv;
> -
> -	priv = phydev->priv;
> -
> -	priv->line_interface = PHY_INTERFACE_MODE_NA;
> -	linkmode_zero(priv->supported);
> -	phydev->port = PORT_NONE;
> -}
             ^^^^

Does priv->line_interface need to be reset when enable is false? The
old mv2222_sfp_remove() explicitly set it to PHY_INTERFACE_MODE_NA,
but the new code leaves it at whatever value was set during the last
module insertion. Functions like mv2222_config_aneg() check whether
priv->line_interface equals PHY_INTERFACE_MODE_NA to determine if a
module is present.

--------x8----------------------------------------------------------------------


Looking at the call-sites, we can see that when the .configure_mii port ops is
called with enabled = false, the interface is always PHY_INTERFACE_MODE_NA.

Looks like the potential problem was identified correctly, but it failed to see
that this can't ever happen. It's a bit tricky I guess, as the call-site in question
is introduced by a previous patch in the same series though.

Maxime

On 11/27/25 10:53 AM, Maxime Chevallier wrote:
> Hi Chris,
> 
> On 27/11/2025 04:00, Jakub Kicinski wrote:
>> On Sat, 22 Nov 2025 13:42:59 +0100 Maxime Chevallier wrote:
>>> This is v19 of the phy_port work. Patches 2 and 3 lack PHY maintainers reviews.
>>>
>>> This v19 has no changes compared to v18, but patch 2 was rebased on top
>>> of the recent 1.6T linkmodes.
>>>
>>> Thanks for everyone's patience and reviews on that work ! Now, the
>>> usual blurb for the series description.
>>
>> Hopefully we can still make v6.19, but we hooked up Claude Code review
>> to patchwork this week, and it points out some legit issues here :(
>> Some look transient but others are definitely legit, please look thru
>> this:
>>

[ ... urls mangled by meta email ... ]

> I was told by Paolo to reach out with any feedback on the LLM reviews :
>

Thanks for sending these along, it really helps me fix up the prompts.

[ ... ]

> 
> Does priv->line_interface need to be reset when enable is false? The
> old mv2222_sfp_remove() explicitly set it to PHY_INTERFACE_MODE_NA,
> but the new code leaves it at whatever value was set during the last
> module insertion. Functions like mv2222_config_aneg() check whether
> priv->line_interface equals PHY_INTERFACE_MODE_NA to determine if a
> module is present.
> 
> --------x8----------------------------------------------------------------------
> 
> 
> Looking at the call-sites, we can see that when the .configure_mii port ops is
> called with enabled = false, the interface is always PHY_INTERFACE_MODE_NA.
> 
> Looks like the potential problem was identified correctly, but it failed to see
> that this can't ever happen.

This is also a problem for bpf reviews, where claude finds a pretty
detailed path to a bug that can never happen in practice.  I'll use this
and a few similar false positive reports to try and improve the
elimination of impossible bugs.

> It's a bit tricky I guess, as the call-site in question
> is introduced by a previous patch in the same series though.

This part shouldn't be a factor (I hope), but I'll check.

-chris

> It's a bit tricky I guess, as the call-site in question
> is introduced by a previous patch in the same series though.

That is an interesting point. Does the AI retain its 'memory' when
processing a patch series. Or does it see each patch individually?

We encourage developers to create lots of small patches, in a patch
series. The AI needs to be able to handle that.

	Andrew

On 11/27/25 11:03 AM, Andrew Lunn wrote:
>> It's a bit tricky I guess, as the call-site in question
>> is introduced by a previous patch in the same series though.
> 
> That is an interesting point. Does the AI retain its 'memory' when
> processing a patch series. Or does it see each patch individually?
> 
> We encourage developers to create lots of small patches, in a patch
> series. The AI needs to be able to handle that.

Hi everyone,

The current prompts don't have a good way to find other commits in the
series and look for later patches fixing issues it has flagged.

This is a common problem on the bpf reviews too, and I've been meaning
to tackle it for a while.  Claude can already wander through git commits
pretty effectively, so I think we just need to pass both ends of the git
range that make up the series.  I'll experiment with that next week.

-chris

Hi Jakub,

On 27/11/2025 04:00, Jakub Kicinski wrote:
> On Sat, 22 Nov 2025 13:42:59 +0100 Maxime Chevallier wrote:
>> This is v19 of the phy_port work. Patches 2 and 3 lack PHY maintainers reviews.
>>
>> This v19 has no changes compared to v18, but patch 2 was rebased on top
>> of the recent 1.6T linkmodes.
>>
>> Thanks for everyone's patience and reviews on that work ! Now, the
>> usual blurb for the series description.
> 
> Hopefully we can still make v6.19, but we hooked up Claude Code review
> to patchwork this week, and it points out some legit issues here :(
> Some look transient but others are definitely legit, please look thru
> this:
> 
> https://netdev-ai.bots.linux.dev/ai-review.html?id=5388d317-98c9-458e-8655-d60f31112574

Is there a canonical way to reply to these reviews ? Some are good, some
aren't.

I'll summarize what I've done in the changelog, but it skips any
potential discussions that could've been triggered by these reviews. I
guess this is a matter of letting this process stabilize :)

Anyhow I'm impressed by what it found (when correct), that's pretty nice.

Maxime

On 11/27/25 11:10 AM, Maxime Chevallier wrote:
> On 27/11/2025 04:00, Jakub Kicinski wrote:
>> On Sat, 22 Nov 2025 13:42:59 +0100 Maxime Chevallier wrote:
>>> This is v19 of the phy_port work. Patches 2 and 3 lack PHY maintainers reviews.
>>>
>>> This v19 has no changes compared to v18, but patch 2 was rebased on top
>>> of the recent 1.6T linkmodes.
>>>
>>> Thanks for everyone's patience and reviews on that work ! Now, the
>>> usual blurb for the series description.
>>
>> Hopefully we can still make v6.19, but we hooked up Claude Code review
>> to patchwork this week, and it points out some legit issues here :(
>> Some look transient but others are definitely legit, please look thru
>> this:
>>
>> https://netdev-ai.bots.linux.dev/ai-review.html?id=5388d317-98c9-458e-8655-d60f31112574
> 
> Is there a canonical way to reply to these reviews ? Some are good, some
> aren't.

AFAIK there isn't yet a formalized process for that.

> I'll summarize what I've done in the changelog, but it skips any
> potential discussions that could've been triggered by these reviews. I
> guess this is a matter of letting this process stabilize :)

If you have time it would be great if you could send an email to Chris
Mason (clm@meta.com) detailing the bad parts and why are incorrect.

Thanks,

Paolo

Hi Jakub,

On 27/11/2025 04:00, Jakub Kicinski wrote:
> On Sat, 22 Nov 2025 13:42:59 +0100 Maxime Chevallier wrote:
>> This is v19 of the phy_port work. Patches 2 and 3 lack PHY maintainers reviews.
>>
>> This v19 has no changes compared to v18, but patch 2 was rebased on top
>> of the recent 1.6T linkmodes.
>>
>> Thanks for everyone's patience and reviews on that work ! Now, the
>> usual blurb for the series description.
> 
> Hopefully we can still make v6.19, but we hooked up Claude Code review
> to patchwork this week, and it points out some legit issues here :(
> Some look transient but others are definitely legit, please look thru
> this:
> 
> https://netdev-ai.bots.linux.dev/ai-review.html?id=5388d317-98c9-458e-8655-d60f31112574

Heh this is actually fairly impressive, I'll go through that :)

Maxime

On Thu, Nov 27, 2025 at 09:43:23AM +0100, Maxime Chevallier wrote:
> Hi Jakub,
> 
> On 27/11/2025 04:00, Jakub Kicinski wrote:
> > On Sat, 22 Nov 2025 13:42:59 +0100 Maxime Chevallier wrote:
> >> This is v19 of the phy_port work. Patches 2 and 3 lack PHY maintainers reviews.
> >>
> >> This v19 has no changes compared to v18, but patch 2 was rebased on top
> >> of the recent 1.6T linkmodes.
> >>
> >> Thanks for everyone's patience and reviews on that work ! Now, the
> >> usual blurb for the series description.
> > 
> > Hopefully we can still make v6.19, but we hooked up Claude Code review
> > to patchwork this week, and it points out some legit issues here :(
> > Some look transient but others are definitely legit, please look thru
> > this:
> > 
> > https://netdev-ai.bots.linux.dev/ai-review.html?id=5388d317-98c9-458e-8655-d60f31112574
> 
> Heh this is actually fairly impressive, I'll go through that :)

Always verify what it says. This is still early testing phase, and we
expect it gets things wrong with quite a high probability.

When it does get it wrong, we would appreciate feedback saying what is
wrong. We can then ask the developer to update the rules to try to
prevent the false positive.

	Andrew