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

[Oleksij Rempel <o.rempel@pengutronix.de>]

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@pengutronix.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 |