Message-ID: <Z3bG-B0E2l47znkE@pengutronix.de>
Date: Thu, 2 Jan 2025 18:03:52 +0100
From: Oleksij Rempel <o.rempel@...gutronix.de>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
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 Thu, Jan 02, 2025 at 10:48:05AM +0000, Russell King (Oracle) wrote:
> 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?

First of all, Happy New Year! :)

I also apologize for the SFP example provided earlier - it was vague, unclear,
and wasted your time. The purpose was not to redefine existing standards but to
demonstrate that even SFP might require separate consideration if we ever move
towards more detailed descriptions. My current focus, however, is on twisted
pair-based Ethernet**, and I’d like to discuss that further if you’re open to
it.

### Why Describe Pair Layouts?

While Ethernet ports often work seamlessly even with misaligned pair layouts
due to PHY auto-correction mechanisms like **MDI-X** or **CD pair swap
correction**, these misalignments can affect diagnostics.  

If pairs are misaligned but still functional in automatic mode, the diagnostic
interface may fail to provide meaningful or accurate data. For example:  
- MDI/MDI-X Detection: Misaligned pairs can lead to unexpected results,
such as both sides reporting the same status when using a non-crossover cable.  
- Debugging Pair Issues: Without proper correction data in the DT, it
becomes challenging to identify and validate pair swaps (e.g., A<>B or C<>D)
during diagnostics.  

Including pair layout information in the DT ensures that the diagnostic
interface can apply necessary corrections, making diagnostics usable.

### Why Address Polarity?  

Polarity detection and correction are mandatory, and all modern PHYs handle it
seamlessly. However, Open Alliance standards require polarity indication
and the ability for manual correction, particularly for automotive-grade
PHYs (e.g., 1000BaseT1, 100BaseT1).  
(See: 6.4 Polarity Detection and Correction (POL))
https://opensig.org/wp-content/uploads/2024/01/Advanced_PHY_features_for_automotive_Ethernet_V1.0.pdf
(Example of non-automotive PHYs supporting polarity indication and disabling of
auto correction)
https://ww1.microchip.com/downloads/en/DeviceDoc/VMDS-10242.pdf

When polarity within the pair becomes relevant for diagnostics, proper PCB
layout becomes crucial. It’s not uncommon for the PCB connection to differ from
the expected polarity at the physical port. Including polarity details in the
DT allows for better alignment between hardware and software diagnostics,
ensuring issues can be detected and corrected efficiently.  

### Why Mention Shielding?

Shielding impacts EMI performance and compatibility, and knowing the shielding
type (e.g., grounded, floating, capacitive) helps in:  

- Cable Selection: Ensures compatibility between shielded/unshielded cables
  and port design.  
- EMI Troubleshooting: Identifies issues in noisy environments or mismatched
  configurations.  
- System Design: Prevents ground loops and ensures compliance with EMC
  standards.  

Even though this information should ideally be part of the product
documentation, having it accessible through the interface makes
software-supported diagnostics much more convenient. For example, software
could guide users by stating:  "This controller has floating shielding. Ensure
the cable is unshielded, or if shielded, it must be properly terminated at
least on one side."  

### Why Mention Magnetics (Transformers)?  

We have to deal with different types of connections: with or without magnetics.
Magnetics themselves come in various types and can be classified by their
common-mode rejection elements, number of cores, and other
characteristics.  

From a software or user perspective, knowing the type and model of the
magnetics is useful for several reasons. For example:  

- The transformer model do affect Time Domain Reflectometry offsets, sometimes
  resulting in discrepancies of several meters.
  (See: TDR Offset Calibration)
  https://www.analog.com/en/resources/app-notes/an-2553.html
  https://ww1.microchip.com/downloads/en/Appnotes/VPPD-01740.pdf

- Transformers influence insertion loss and exhibit varying noise
  characteristics, both of which impact the analog properties of signals.  

- Some PHYs support tuning their analog characteristics (e.g., VoD swing,
  impedance matching) based on the attached magnetics. Advanced PHYs with such
  capabilities are often found in industrial-grade PHYs.
  (See: How to Tune DP83825 VoD Swing)
  https://www.ti.com/lit/an/snla266a/snla266a.pdf
  
Best regards,  
Oleksij
-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Powered by blists - more mailing lists