linux-kernel - 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] [day] [month] [year] [list]

Message-ID: <Z34zUuUkx2bWXYfW@pengutronix.de>
Date: Wed, 8 Jan 2025 09:12:02 +0100
From: Oleksij Rempel <o.rempel@...gutronix.de>
To: Maxime Chevallier <maxime.chevallier@...tlin.com>
Cc: Andrew Lunn <andrew@...n.ch>,
	"Russell King (Oracle)" <linux@...linux.org.uk>,
	Kory Maincent <kory.maincent@...tlin.com>, davem@...emloft.net,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	thomas.petazzoni@...tlin.com, 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 Wed, Jan 08, 2025 at 08:25:07AM +0100, Maxime Chevallier wrote:
> On Tue, 7 Jan 2025 17:41:30 +0100
> Oleksij Rempel <o.rempel@...gutronix.de> wrote:
> 
> > On Tue, Jan 07, 2025 at 05:22:51PM +0100, Andrew Lunn wrote:
> > > >   I have however seen devices that have a 1G PHY connected to a RJ45
> > > > port with 2 lanes only, thus limiting the max achievable speed to 100M.
> > > > Here, we would explicietly describe the port has having 2 lanes.   
> > 
> > I can confirm existence of this kind of designs. One industrial real life
> > example: a SoC connected to 3 port Gigabit KSZ switch. One port is
> > typical RJ45 connector. Other port is RJ11 connector.
> > 
> > The speed can be reduced by using max-speed property. But i can't
> > provide any user usable diagnostic information just by saying pair A or
> > B is broken.
> > 
> > This is one of the reasons why i propose detailed description.
> 
> While I get the point, I'm wondering if it's relevant to expose this
> diag information for the user. As this is a HW design feature we're
> representing, and it's described in devicetree, the information that the
> HW design is wrong or uncommon is already known. So, exposing this to
> the user ends-up being a pretty way to display plain devicetree data,
> without much added value from the PHY stack ? Or am I missing the point
> ?

Correct. The same kind of information, such as whether the connector is RJ45 or
an industrial one with a proprietary layout, or what label this port will have
on the box, is essential. This information helps the user to manage, repair, or
connect devices in the field - even after 30 years of operation, when no paper
manual has survived being eaten by animals and the vendor's websites no longer
exist.

Here is one example of an industrial switch with PoE support:                                                                                       
https://www.westermo.com/-/media/Files/User-guides/westermo_ug_6641-22501_viper-x12a-poe_revo.pdf?rev=083148a9e565416a9044e9a4e379635f              
                                                                                                                                                    
Please pay attention to the difference for Gbit and 100Mbit ports and signal
layout within this ports.

> I would see some value if we could detect that pairs are miswired or
> disconnected at runtime, then report this to user. Here the information
> is useful.

Ack.
 
> The minimal information needed by software is in that case "how many
> working pairs are connected between the PHY and the connector", and
> possibly "are they swapped ?"

In case of home and enterprise type of devices - yes.
In case of industrial - the devices can be certified to operate in some
specific link mode.

For example device certified for explosive environments. These device should
operate in 10BaseT1L-Vpp1 mode only, and discard any link attempts to
devices which advertise 10BaseT1L-Vpp2 support in addition to 10BaseT1L-Vpp1:
https://www.pepperl-fuchs.com/germany/de/classid_260.htm?view=productdetails&prodid=118298

My point is, if we will need to set limit for the link modes, soon or later,
we will need a supported linkmodes property and this property will partially
duplicated the lanes property. At same time, if we use supported linkmodes
instead of lanes, we solve the problem with multimode PHYs which support
twisted pair and fiber modes.

-- 
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 |