On 9/9/25 08:25, Maxime Chevallier wrote:

Hi everyone,

Here is a V12 for the phy_port work, aiming at representing the
connectors and outputs of PHY devices.

Last round was 16 patches, and now 18, if needed I can split some
patches out such as the 2 phylink ones.

this V12 address the SFP interface selection for PHY driver SFPs, as
commented by Russell on v10.

This and Rob's review on the dp83822 patch are the only changes.

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,

Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>

Tested with bcmgenet which is single MAC + PHY using phylib.

Tested with bcm_sf2 which uses phylink and has a combination of internal 
and external PHYs.
--
Florian
-- 
Florian