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: <Z3weP2JpURuRgHnb@pengutronix.de>
Date: Mon, 6 Jan 2025 19:17:35 +0100
From: Oleksij Rempel <o.rempel@...gutronix.de>
To: Kory Maincent <kory.maincent@...tlin.com>
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>,
	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>,
	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 Sat, Jan 04, 2025 at 11:23:59PM +0100, Kory Maincent wrote:
> On Sun, 22 Dec 2024 19:54:37 +0100
> Oleksij Rempel <o.rempel@...gutronix.de> wrote:
> >         pse = <&pse1>; /* Reference to the attached PSE controller */
> 
> The PSE pairset and polarity are already described in the PSE bindings.
> https://elixir.bootlin.com/linux/v6.12.6/source/Documentation/devicetree/bindings/net/pse-pd/pse-controller.yaml
> 
> I am not sure it is a good idea to have PSE information at two different places.

You are right, the PSE PI node already covers the IEEE specifications. But
there are still some missing pieces. These are not directly tied to the PSE but
are important for port functionality, like LEDs, thermal sensors, and
transformer characteristics.  

### Why Link to the Port Node  

While LEDs, thermal zones, and other components can be described in the Device
Tree, there’s currently no clear way to indicate which ones belong to a
specific port. For single-port devices, this isn’t a big issue, but for devices
like switches with multiple ports, it gets messy very quickly.  

For example:  
- LEDs: Each port may have multiple LEDs for link, activity, and PoE
status. Without linking them to specific ports, the software cannot correctly
map these LEDs to their respective functionalities.

- Thermal Sensors: Sensors located near specific ports or magnetics are crucial
for thermal management. If they aren’t linked to a port, it’s unclear which
sensor data applies to which port.  

### Why Transformer Characteristics Matter  

Transformers (magnetics) are critical for Ethernet and affect software in these
ways:  

1. Signal Integrity:  
   - Transformers influence noise and insertion loss.
   - Some PHYs allow analog tuning for the connected transformer. Software
     needs this information to configure PHY registers for optimal performance.  

2. Power Delivery:  
   - Transformers have power and current limits.  
   - Software must ensure the power budget stays within these limits and detect
     overcurrent conditions.  

3. Thermal Management:  
   - Transformers can overheat under load.
   - Software should monitor nearby sensors and reduce power if temperatures
     exceed safe levels.  

This functionality does not need to be added right now. However, I’ve
encountered some of these issues and believe they may impact others sooner or
later. It would be good if newly added specifications avoid conflicting with or
blocking potential solutions to these known issues.

> > In case of PoDL, we will have something like this:
> > 
> > pair@0 {
> >     name = "A"; /* Single pair for 10BaseT1L */
> >     pins = <1 2>; /* Connector pins */
> >     phy-mapping = <PHY_TXRX0_P PHY_TXRX0_N>; /* PHY pin mapping */
> >     podl-mapping = <PODL_OUT0_P PODL_OUT0_N>; /* PoDL mapping: Positive and
> > negative outputs */ };
> 
> We should do the same for PoDL. Put all information in the same place, the PSE
> bindings.

Ack.

Since IEEE does not provide anything beyond pinout and polarity description for
PSE PI specifications (at least for PoE variants), let's keep those details
there. Magnetics, being a shared component, should be described as part of the
port. Thermal sensors located near magnetics or physical ports are port-related
and should also be linked to the port. LEDs, however, fall into different
groups: some are connected to PHYs, others to PSE, and they may be controlled
by PHYs, PSE, or external controllers with software. These LEDs need a clear
linkage to their corresponding port functionality. What would be the best way
to establish this linkage without introducing unnecessary complexity?

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 |