Hello everyone,

This series follows the 2 RFC that were sent a few weeks ago :
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/

The goal of this series is to introduce an internal way of representing
the "outputs" of ethernet devices, for now only focusing on PHYs.

This allows laying the groundwork for multi-port devices support (both 1
PHY 2 ports, or more exotic setups with 2 PHYs in parallel, or MII
multiplexers).

Compared to the RFCs, this series tries to properly support SFP,
especially PHY-driven SFPs through special phy_ports named "serdes"
ports. They have the particularity of outputing a generic interface,
that feeds into another component (usually, an SFP cage and therefore an
SFP module).

This allows getting a fairly generic PHY-driven SFP support (MAC-driven
SFP is handled by phylink).

This series doesn't address PHY-less interfaces (bare MAC devices, MACs
with embedded PHYs not driven by phylink, or MAC connected to optical
SFPs) to stay within the 15 patches limit, nor does it include the uAPI
part that exposes these ports to userspace.

I've kept the cover short, much more details can be found in the RFC
covers.

Thanks everyone,

Maxime

Maxime Chevallier (13):
  net: ethtool: Introduce ETHTOOL_LINK_MEDIUM_* values
  net: ethtool: Export the link_mode_params definitions
  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: Intrduce 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: Only rely on phy_port for PHY-driven SFP
  net: phy: dp83822: Add SFP support through the phy_port interface
  dt-bindings: net: Introduce the phy-port description

 .../devicetree/bindings/net/ethernet-phy.yaml |  18 +
 .../bindings/net/ethernet-port.yaml           |  47 +++
 drivers/net/phy/Makefile                      |   2 +-
 drivers/net/phy/dp83822.c                     |  71 ++--
 drivers/net/phy/marvell-88x2222.c             |  96 +++---
 drivers/net/phy/marvell.c                     | 100 +++---
 drivers/net/phy/marvell10g.c                  |  37 +--
 drivers/net/phy/phy_device.c                  | 307 +++++++++++++++++-
 drivers/net/phy/phy_port.c                    | 176 ++++++++++
 drivers/net/phy/phylink.c                     |  32 ++
 drivers/net/phy/qcom/at803x.c                 |  64 +---
 include/linux/ethtool.h                       |  73 +++++
 include/linux/phy.h                           |  39 ++-
 include/linux/phy_port.h                      |  92 ++++++
 include/linux/phylink.h                       |   2 +
 net/ethtool/common.c                          | 231 ++++++-------
 net/ethtool/common.h                          |   7 -
 17 files changed, 1048 insertions(+), 346 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/net/ethernet-port.yaml
 create mode 100644 drivers/net/phy/phy_port.c
 create mode 100644 include/linux/phy_port.h

-- 
2.48.1

On Fri, Feb 07, 2025 at 11:36:19PM +0100, Maxime Chevallier wrote:
> Hello everyone,
> 
> This series follows the 2 RFC that were sent a few weeks ago :
> 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/

That makes this series v3. RFC is not a version, but a condition the 
patches are in (not ready to merge).

Rob

Hello Rob,

On Wed, 12 Feb 2025 13:48:08 -0600
Rob Herring <robh@kernel.org> wrote:

> On Fri, Feb 07, 2025 at 11:36:19PM +0100, Maxime Chevallier wrote:
> > Hello everyone,
> > 
> > This series follows the 2 RFC that were sent a few weeks ago :
> > 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/  
> 
> That makes this series v3. RFC is not a version, but a condition the 
> patches are in (not ready to merge).

Fair enough, next iteration will be V4 then :)

Thanks,

Maxime

> Rob

Hi Maxime,

On 2/7/25 17:36, Maxime Chevallier wrote:
> Hello everyone,
> 
> This series follows the 2 RFC that were sent a few weeks ago :
> 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/
> 
> The goal of this series is to introduce an internal way of representing
> the "outputs" of ethernet devices, for now only focusing on PHYs.
> 
> This allows laying the groundwork for multi-port devices support (both 1
> PHY 2 ports, or more exotic setups with 2 PHYs in parallel, or MII
> multiplexers).
> 
> Compared to the RFCs, this series tries to properly support SFP,
> especially PHY-driven SFPs through special phy_ports named "serdes"
> ports. They have the particularity of outputing a generic interface,
> that feeds into another component (usually, an SFP cage and therefore an
> SFP module).
> 
> This allows getting a fairly generic PHY-driven SFP support (MAC-driven
> SFP is handled by phylink).
> 
> This series doesn't address PHY-less interfaces (bare MAC devices, MACs
> with embedded PHYs not driven by phylink, or MAC connected to optical
> SFPs) to stay within the 15 patches limit, nor does it include the uAPI
> part that exposes these ports to userspace.
> 
> I've kept the cover short, much more details can be found in the RFC
> covers.
> 
> Thanks everyone,
> 
> Maxime

Forgive me for my ignorance, but why have a new ethtool interface instead of
extending ethtool_link_settings.port? It's a rather ancient interface, but it
seems to be tackling the exact same problem as you are trying to address. Older
NICs used to have several physical connectors (e.g. BNC, MII, twisted-pair) but
only one could be used at once. This seems directly analogous to a PHY that
supports multiple "port"s but not all at once. In fact, the only missing
connector type seems to be PORT_BACKPLANE.

I can think of a few reasons why you wouldn't use PORT_*:

- It describes the NIC and not the PHY, and perhaps there is too much impedance
   mismatch?
- There is too much legacy in userspace (or in the kernel) to use that API in
   this way?
- You need more flexibility?

At the very least, I think some discussion in one of the commits would be
warranted. Perhaps there was some on the RFC that I missed?

--Sean

Hi Sean,

On Fri, 7 Feb 2025 21:14:32 -0500
Sean Anderson <seanga2@gmail.com> wrote:

> Hi Maxime,
> 
> On 2/7/25 17:36, Maxime Chevallier wrote:
> > Hello everyone,
> > 
> > This series follows the 2 RFC that were sent a few weeks ago :
> > 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/
> > 
> > The goal of this series is to introduce an internal way of representing
> > the "outputs" of ethernet devices, for now only focusing on PHYs.
> > 
> > This allows laying the groundwork for multi-port devices support (both 1
> > PHY 2 ports, or more exotic setups with 2 PHYs in parallel, or MII
> > multiplexers).
> > 
> > Compared to the RFCs, this series tries to properly support SFP,
> > especially PHY-driven SFPs through special phy_ports named "serdes"
> > ports. They have the particularity of outputing a generic interface,
> > that feeds into another component (usually, an SFP cage and therefore an
> > SFP module).
> > 
> > This allows getting a fairly generic PHY-driven SFP support (MAC-driven
> > SFP is handled by phylink).
> > 
> > This series doesn't address PHY-less interfaces (bare MAC devices, MACs
> > with embedded PHYs not driven by phylink, or MAC connected to optical
> > SFPs) to stay within the 15 patches limit, nor does it include the uAPI
> > part that exposes these ports to userspace.
> > 
> > I've kept the cover short, much more details can be found in the RFC
> > covers.
> > 
> > Thanks everyone,
> > 
> > Maxime  
> 
> Forgive me for my ignorance, but why have a new ethtool interface instead of
> extending ethtool_link_settings.port? It's a rather ancient interface, but it
> seems to be tackling the exact same problem as you are trying to address. Older
> NICs used to have several physical connectors (e.g. BNC, MII, twisted-pair) but
> only one could be used at once. This seems directly analogous to a PHY that
> supports multiple "port"s but not all at once. In fact, the only missing
> connector type seems to be PORT_BACKPLANE.
> 
> I can think of a few reasons why you wouldn't use PORT_*:
> 
> - It describes the NIC and not the PHY, and perhaps there is too much impedance
>    mismatch?
> - There is too much legacy in userspace (or in the kernel) to use that API in
>    this way?
> - You need more flexibility?

So there are multiple reasons that make the PORT_* field limited :

 - We can't gracefully handle multi-port PHYs for complex scenarios
where we could say "I'm currently using the Copper port, but does the
Fiber port has link ?"

 - As you mention in your first argument, what I'd like to try to do is
come-up with a "generic" representation of outgoing NIC interfaces. The
final use-cases I'd like to cover are multi-port NICs, allowing
userspace to control which physical interfaces are available, and which
t use. Looking at the hardware, this can be implemented in multiple
ways :

           ___ Copper
          /
 MAC - PHY
          \__ SFP

Here, a single PHY has 2 media-side interfaces, and we'd like to select
the one to use. That's fairly common now, there are quite a number of
PHYs that support this : mv33x3310, VSC8552, mv88x2222 only to name a
few. But there are other, more uncommon topologies that exist :

                           ____ SGMII PHY -- Copper
                          /
 MAC - SGMII/1000BaseX MUX
                          \____ SFP

Here, we also have 2 media-side ports, but they are driver through
different entities : The Copper port sits behind a single-port PHY,
that is itself behind a *MII MUX, that's also connected to an SFP. Here
the port selection is done at the MUX level

Finally, I've been working on supporting devices whith another topology
(actually, what started this whole work) :

            ___ PHY
           /
 MAC --MUX |
           \__ PHY

Here both PHYs are on the same *MII bus, with some physical,
gpio-driven MUX, and we have 2 PORT_TP on the same NIC. That design is
used for link redundancy, if one PHY loses the link, we switch to the
other one (that hopefully has link).

All these cases have different drivers involved in the MUX'ing (phy
driver itself, intermediate MUX in-between...), so the end-goal would
be to expose to userspace info about the media interfaces themselves.

This phy_port object would be what we expose to userspace. One missing
step in this series is adding control on the ports (netlink API,
enabling/disabling logic for ports) but that far exceeds the 15 patches
limitation :)

Sorry if all of that was blurry, I did make so good of a job linking to
all previous discussions on the topic, I'll address that for the next
round.

Thanks,

Maxime

Hi Maxime,

On 2/10/25 03:55, Maxime Chevallier wrote:
> Hi Sean,
> 
> On Fri, 7 Feb 2025 21:14:32 -0500
> Sean Anderson <seanga2@gmail.com> wrote:
> 
>> Hi Maxime,
>>
>> On 2/7/25 17:36, Maxime Chevallier wrote:
>>> Hello everyone,
>>>
>>> This series follows the 2 RFC that were sent a few weeks ago :
>>> 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/
>>>
>>> The goal of this series is to introduce an internal way of representing
>>> the "outputs" of ethernet devices, for now only focusing on PHYs.
>>>
>>> This allows laying the groundwork for multi-port devices support (both 1
>>> PHY 2 ports, or more exotic setups with 2 PHYs in parallel, or MII
>>> multiplexers).
>>>
>>> Compared to the RFCs, this series tries to properly support SFP,
>>> especially PHY-driven SFPs through special phy_ports named "serdes"
>>> ports. They have the particularity of outputing a generic interface,
>>> that feeds into another component (usually, an SFP cage and therefore an
>>> SFP module).
>>>
>>> This allows getting a fairly generic PHY-driven SFP support (MAC-driven
>>> SFP is handled by phylink).
>>>
>>> This series doesn't address PHY-less interfaces (bare MAC devices, MACs
>>> with embedded PHYs not driven by phylink, or MAC connected to optical
>>> SFPs) to stay within the 15 patches limit, nor does it include the uAPI
>>> part that exposes these ports to userspace.
>>>
>>> I've kept the cover short, much more details can be found in the RFC
>>> covers.
>>>
>>> Thanks everyone,
>>>
>>> Maxime
>>
>> Forgive me for my ignorance, but why have a new ethtool interface instead of
>> extending ethtool_link_settings.port? It's a rather ancient interface, but it
>> seems to be tackling the exact same problem as you are trying to address. Older
>> NICs used to have several physical connectors (e.g. BNC, MII, twisted-pair) but
>> only one could be used at once. This seems directly analogous to a PHY that
>> supports multiple "port"s but not all at once. In fact, the only missing
>> connector type seems to be PORT_BACKPLANE.
>>
>> I can think of a few reasons why you wouldn't use PORT_*:
>>
>> - It describes the NIC and not the PHY, and perhaps there is too much impedance
>>     mismatch?
>> - There is too much legacy in userspace (or in the kernel) to use that API in
>>     this way?
>> - You need more flexibility?
> 
> So there are multiple reasons that make the PORT_* field limited :
> 
>   - We can't gracefully handle multi-port PHYs for complex scenarios
> where we could say "I'm currently using the Copper port, but does the
> Fiber port has link ?"
> 
>   - As you mention in your first argument, what I'd like to try to do is
> come-up with a "generic" representation of outgoing NIC interfaces. The
> final use-cases I'd like to cover are multi-port NICs, allowing
> userspace to control which physical interfaces are available, and which
> t use. Looking at the hardware, this can be implemented in multiple
> ways :
> 
>             ___ Copper
>            /
>   MAC - PHY
>            \__ SFP
> 
> Here, a single PHY has 2 media-side interfaces, and we'd like to select
> the one to use. That's fairly common now, there are quite a number of
> PHYs that support this : mv33x3310, VSC8552, mv88x2222 only to name a
> few. But there are other, more uncommon topologies that exist :
> 
>                             ____ SGMII PHY -- Copper
>                            /
>   MAC - SGMII/1000BaseX MUX
>                            \____ SFP
> 
> Here, we also have 2 media-side ports, but they are driver through
> different entities : The Copper port sits behind a single-port PHY,
> that is itself behind a *MII MUX, that's also connected to an SFP. Here
> the port selection is done at the MUX level
> 
> Finally, I've been working on supporting devices whith another topology
> (actually, what started this whole work) :
> 
>              ___ PHY
>             /
>   MAC --MUX |
>             \__ PHY
> 
> Here both PHYs are on the same *MII bus, with some physical,
> gpio-driven MUX, and we have 2 PORT_TP on the same NIC. That design is
> used for link redundancy, if one PHY loses the link, we switch to the
> other one (that hopefully has link).
> 
> All these cases have different drivers involved in the MUX'ing (phy
> driver itself, intermediate MUX in-between...), so the end-goal would
> be to expose to userspace info about the media interfaces themselves.
> 
> This phy_port object would be what we expose to userspace. One missing
> step in this series is adding control on the ports (netlink API,
> enabling/disabling logic for ports) but that far exceeds the 15 patches
> limitation :)
> 
> Sorry if all of that was blurry, I did make so good of a job linking to
> all previous discussions on the topic, I'll address that for the next
> round.

Thanks for the detailed explanation, especially regarding PHY redundancy.
Could you add it to a commit message (or even better to Documentation/)?

--Sean

Hello Sean,

On Wed, 12 Feb 2025 10:39:48 -0500
Sean Anderson <seanga2@gmail.com> wrote:


> > Sorry if all of that was blurry, I did make so good of a job linking to
> > all previous discussions on the topic, I'll address that for the next
> > round.  
> 
> Thanks for the detailed explanation, especially regarding PHY redundancy.
> Could you add it to a commit message (or even better to Documentation/)?

Sure thing :)

Thanks,

Maxime