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: <Z3Zu5ZofHqy4vGoG@shell.armlinux.org.uk>
Date: Thu, 2 Jan 2025 10:48:05 +0000
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Oleksij Rempel <o.rempel@...gutronix.de>
Cc: 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>,
	Köry Maincent <kory.maincent@...tlin.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 Sun, Dec 22, 2024 at 07:54:37PM +0100, Oleksij Rempel wrote:
> Here is updated version:
> 
> ports {
>     /* 1000BaseT Port with Ethernet and simple PoE */
>     port0: ethernet-port@0 {
>         reg = <0>; /* Port index */
>         label = "ETH0"; /* Physical label on the device */
>         connector = "RJ45"; /* Connector type */
>         supported-modes = <10BaseT 100BaseTX 1000BaseT>; /* Supported modes */
> 
>         transformer {
>             model = "ABC123"; /* Transformer model number */
>             manufacturer = "TransformerCo"; /* Manufacturer name */
> 
>             pairs {
>                 pair@0 {
>                     name = "A"; /* Pair A */
>                     pins = <1 2>; /* Connector pins */
>                     phy-mapping = <PHY_TX0_P PHY_TX0_N>; /* PHY pin mapping */
>                     center-tap = "CT0"; /* Central tap identifier */
>                     pse-negative = <PSE_GND>; /* CT0 connected to GND */
>                 };
>                 pair@1 {
>                     name = "B"; /* Pair B */
>                     pins = <3 6>; /* Connector pins */
>                     phy-mapping = <PHY_RX0_P PHY_RX0_N>;
>                     center-tap = "CT1"; /* Central tap identifier */
>                     pse-positive = <PSE_OUT0>; /* CT1 connected to PSE_OUT0 */
>                 };
>                 pair@2 {
>                     name = "C"; /* Pair C */
>                     pins = <4 5>; /* Connector pins */
>                     phy-mapping = <PHY_TXRX1_P PHY_TXRX1_N>; /* PHY connection only */
>                     center-tap = "CT2"; /* Central tap identifier */
>                     /* No power connection to CT2 */
>                 };
>                 pair@3 {
>                     name = "D"; /* Pair D */
>                     pins = <7 8>; /* Connector pins */
>                     phy-mapping = <PHY_TXRX2_P PHY_TXRX2_N>; /* PHY connection only */
>                     center-tap = "CT3"; /* Central tap identifier */
>                     /* No power connection to CT3 */
>                 };
>             };
>         };

I'm sorry, but... what is the point of giving this much detail in the DT
description. How much of this actually would get used by *any* code?

Why does it matter what transformer is used - surely 802.3 defines the
characteristics of the signal at the RJ45 connector and it's up to the
hardware designer to ensure that those characteristics are met. That
will depend on the transformer, connector and board layout.

What does it matter what connector pins are used? This is standardised.

You also at one point had a description for a SFP cage (I'm sorry, I
can't be bothered to find it in the 3000+ emails that I've missed over
the Christmas period), using pin numbers 1, 2, 3, and 4. That's
nonsense, those aren't the pin numbers for the data pairs. You also
are effectively redefining what already exists for SFP cages - we
already have a DT description for that, and it's based around the
standardised connector. Why do we need a new description for SFP
cages?

Are we going to start converting schematics into DT representations,
including any resistors and capacitors that may be present in the
data path?

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!