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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <7a611937-a2af-4780-9b88-cf9f282f88b3@bootlin.com>
Date: Thu, 30 Oct 2025 15:50:27 +0100
From: Maxime Chevallier <maxime.chevallier@...tlin.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: davem@...emloft.net, netdev@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org,
 thomas.petazzoni@...tlin.com, Jakub Kicinski <kuba@...nel.org>,
 Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>,
 Russell King <linux@...linux.org.uk>, linux-arm-kernel@...ts.infradead.org,
 Christophe Leroy <christophe.leroy@...roup.eu>,
 Herve Codina <herve.codina@...tlin.com>,
 Florian Fainelli <f.fainelli@...il.com>,
 Heiner Kallweit <hkallweit1@...il.com>,
 Vladimir Oltean <vladimir.oltean@....com>,
 Köry Maincent <kory.maincent@...tlin.com>,
 Marek Behún <kabel@...nel.org>,
 Oleksij Rempel <o.rempel@...gutronix.de>,
 Nicolò Veronese <nicveronese@...il.com>,
 Simon Horman <horms@...nel.org>, mwojtas@...omium.org,
 Antoine Tenart <atenart@...nel.org>, devicetree@...r.kernel.org,
 Conor Dooley <conor+dt@...nel.org>, Krzysztof Kozlowski
 <krzk+dt@...nel.org>, Rob Herring <robh@...nel.org>,
 Romain Gantois <romain.gantois@...tlin.com>,
 Daniel Golle <daniel@...rotopia.org>,
 Dimitri Fedrau <dimitri.fedrau@...bherr.com>,
 Florian Fainelli <florian.fainelli@...adcom.com>
Subject: Re: [PATCH net-next v14 01/16] dt-bindings: net: Introduce the
 ethernet-connector description

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