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: <Z31ZOjLcE34CNj0S@pengutronix.de>
Date: Tue, 7 Jan 2025 17:41:30 +0100
From: Oleksij Rempel <o.rempel@...gutronix.de>
To: Andrew Lunn <andrew@...n.ch>
Cc: Maxime Chevallier <maxime.chevallier@...tlin.com>,
	"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, 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.

> Some PHYs would handle this via downshift, detecting that some pairs
> are broken, and then dropping down to 100M on their own. So it is not
> always necessary to have a board property, at least not for data.

Ack, but it will work not for all setups.

> I've no idea how this affects power transfer. Can the link partners
> detect which pairs are actually wired?

Not is usual simple implementation. The PSE PI devicetree properties
provide enough information for a _standard_ use case.

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