netdev - Re: [PATCH net-next RFC 0/5] net: phy: Introduce a port representation

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: <20250107154302.628e7982@kmaincent-XPS-13-7390>
Date: Tue, 7 Jan 2025 15:43:02 +0100
From: Kory Maincent <kory.maincent@...tlin.com>
To: Oleksij Rempel <o.rempel@...gutronix.de>
Cc: "Russell King (Oracle)" <linux@...linux.org.uk>, Maxime Chevallier
 <maxime.chevallier@...tlin.com>, davem@...emloft.net,
 netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
 thomas.petazzoni@...tlin.com, Andrew Lunn <andrew@...n.ch>, Jakub Kicinski
 <kuba@...nel.org>, Eric Dumazet <edumazet@...gle.com>, Paolo Abeni
 <pabeni@...hat.com>, 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>, Marek
 Behún <kabel@...nel.org>, Nicolò Veronese
 <nicveronese@...il.com>, Simon Horman <horms@...nel.org>,
 mwojtas@...omium.org, Antoine Tenart <atenart@...nel.org>
Subject: Re: [PATCH net-next RFC 0/5] net: phy: Introduce a port
 representation

On Tue, 7 Jan 2025 15:02:46 +0100
Oleksij Rempel <o.rempel@...gutronix.de> wrote:

> On Tue, Jan 07, 2025 at 02:26:05PM +0100, Kory Maincent wrote:
> > On Thu, 2 Jan 2025 18:03:52 +0100
> > Oleksij Rempel <o.rempel@...gutronix.de> wrote:
> >   
> > > On Thu, Jan 02, 2025 at 10:48:05AM +0000, Russell King (Oracle) wrote:  
>  [...]  
>  [...]  
> > 
> > Couldn't we begin with something simple like the following and add all the
> > transformers and pairs information as you described later if the community
> > feels we need it?
> > 
> > mdis {
> > 
> >     /* 1000BaseT Port with Ethernet and PoE */
> >     mdi0: ethernet-mdi@0 {
> >         reg = <0>; /* Port index */
> >         label = "ETH0"; /* Physical label on the device */
> >         connector = "RJ45"; /* Connector type */
> >         supported-modes = <10BaseT 100BaseTX 1000BaseT>; /* Supported modes
> > */ lanes = <2>;
> >         variant = "MDI-X"; /* MDI or MDI-X */
> >         pse = <&pse1>;
> >     };
> > };  
> 
> The problematic properties are lanes and variants.
> 
> Lanes seems to not provide any additional information which is not
> provided by the supported-modes.
> 
> We have at least following working variants, which are supported by (some?)
> microchip PHYs:
> https://microchip.my.site.com/s/article/1000Base-T-Differential-Pair-Swapping
> For swapping A and B pairs, we may use MDI/MDI-X. What is about swapped
> C and D pairs?
> 
> The IEEE 802.3 - 2022 has following variants:
> 14.5.2 Crossover function - only A<>B swap is supported
> 40.4.4 Automatic MDI/MDI-X Configuration - only A<>B swap is supported?
> 55.4.4 Automatic MDI/MDI-X configuration - 4 swap variants are supported
> 113.4.4 Automatic MDI/MDI-X configuration - 4 swap variants are supported
> 126.4.4 Automatic MDI/MDI-X configuration - 4 swap variants are supported
> 
> This was only the pair swap. How to reflect the polarity swap withing
> the pairs?

Indeed I see what you mean. Maybe we could add it later as optional binding and
only focus for now on the current needs.
According to Maxime proposition he wants the connector types and the
supported modes (or number of lanes). On my side I am interested in the PSE
phandle.

We could begin with this:
mdis {
    /* 1000BaseT Port with Ethernet and PoE */
    mdi0: ethernet-mdi@0 {
        reg = <0>; /* Port index */
        label = "ETH0"; /* Physical label on the device */
        connector = "RJ45"; /* Connector type */
        supported-modes = <10BaseT 100BaseTX 1000BaseT>; /* Supported modes */
        pse = <&pse1>;
    };
};  

Your proposition will stay in our mind for future development on the subject.
I think we currently don't have enough time available to develop the full
package.
What do you think?

Regards,
-- 
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com