Re: [PATCH net-next v14 01/16] dt-bindings: net: Introduce the ethernet-connector description

[Maxime Chevallier <maxime.chevallier@bootlin.com>]

Hi Andrew, thanks for the reply !

On 30/10/2025 14:23, Andrew Lunn wrote:
> On Thu, Oct 30, 2025 at 01:13:14PM +0100, Maxime Chevallier wrote:
>> Hi,
>>
>>> @@ -313,5 +324,12 @@ examples:
>>>                      default-state = "keep";
>>>                  };
>>>              };
>>> +            /* Fast Ethernet port, with only 2 pairs wired */
>>> +            mdi {
>>> +                connector-0 {
>>> +                    lanes = <2>;
>>> +                    media = "BaseT";
>>> +                };
>>> +            };
>>>          };
>>>      };
>>
>> As Andrew suggest clearly differentiating "lanes" and "pairs", do we
>> want this difference to also affect the binding ?
>>
>> I still think "lanes" makes some level of sense here, but at least
>> the doc will need updating.
> 
> How do you define MDI?
> 
> For copper, one possibility is an RJ-45 plug/socket, and you have
> twisted pairs, 2 or 4 of them.
> 
> Some people are old enough to remember 10Base2, using a coaxial cable
> and BNC connectors. Would you consider that a pair? A lane?
> 
> How about an SFF, a soldered down module. Its MDI interface is likely
> to be 2 fibre strands. But consider so called bidi modules, which use
> one fibre, and two different wavelengths of light.
> 
> Or an SFP, where you have no idea what the MDI is until you plug it in
> and read the EEPROM.
> 
> Do we need to be able to describe all the different MDI? Do we maybe
> need to look at the media property to decide it is an RJ-45 connector
> so there should be a pairs property? Or the media is -KS, so there
> should be a lanes property for the number of PCS lanes on the PCB?
> 
> This needs further discussion, what are you actually trying to
> represent here?

What I'd like to represent here is at least BaseT connectors, or simple
Fiber connectors without SFF/SFP (we already have an sff/sfp description
in DT, and we can know what they do by reading the eeprom).

Let's consider these examples, which are representative of what I
want to represent and why.

As a remainder, the end-goal is to be able to list to userspace the
front-facing ports that are beind a netdev, so that we can in the end
support MII-side muxing.

We have several examples of that already upstream :
 - Turris omnia, where we have a mux in the SoC to output the SGMII/1000BaseX
  either on a PHY or an SFP port. This is not covered by this series.

 - The MCBin Doubleshot. Here we have the Marvell 88x3310 PHY connected to the MAC,
and to both an SFP and a RJ45.

However, what we have in DT is :


&cp0_xmdio {
	status = "okay";

	phy0: ethernet-phy@0 {
		compatible = "ethernet-phy-ieee802.3-c45";
		reg = <0>;
		sfp = <&sfp_eth0>;
	};

	[...]
};

The question is, with the information we have in DT and from what the PHY
can autodiscover, how do we know if we have this :

MAC --- PHY ---- SFP

or this :

MAC ---PHY ----SFP
        \-----RJ45

I don't think we can, we are missing a description of the MDI-side of the PHY.

Of course I don't want to start representing the MDI for every PHY out
there, most common case we have one MDI, that supports whatever the PHY
reports from .get_features(), with the possibility of reading some straps to
adjust.

When we start representing the MDI, we can take that opportunity to solve other
problems :

 - The proliferation of vendor properties like "ti,fiber-mode" or "micrel,fiber-mode"
 - The use of "max-speed = <100>;" because the PHY is only connected to the RJ45 with
   2 pairs

So that being said, an option could be to only focus on pairs, only for medium = BaseT,
and ditch the "lanes" terminology, at least when it comes to the DT bindings.

Does that sound good ?

Maxime