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: <20250108082507.0402f158@fedora.home>
Date: Wed, 8 Jan 2025 08:25:07 +0100
From: Maxime Chevallier <maxime.chevallier@...tlin.com>
To: Oleksij Rempel <o.rempel@...gutronix.de>
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 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
?

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.

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 ?" but I think we already have a DT property
for that ?

Maxime