netdev - Re: [PATCH 0/2] net: phy: dp83822: Add support for line class driver configuration

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]

Date: Tue, 11 Jul 2023 17:35:32 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Vesa Jääskeläinen <vesa.jaaskelainen@...sala.com>
Cc: "David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Rob Herring <robh+dt@...nel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Heiner Kallweit <hkallweit1@...il.com>,
	Russell King <linux@...linux.org.uk>, Andrew Davis <afd@...com>,
	netdev@...r.kernel.org, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] net: phy: dp83822: Add support for line class driver
 configuration

On Tue, Jul 11, 2023 at 10:51:22AM +0300, Vesa Jääskeläinen wrote:
> Hi Andrew,
> 
> On 10.7.2023 22.38, Andrew Lunn wrote:
> > > Hi Andrew,
> > > 
> > > This is needed for configuration in link between DP83822 and Ethernet Switch
> > > chip.
> > What switch chip is it?
> 
> Microchip's KSZ9897.

O.K, so nothing special or oddball.

> > Most boards just connect the MACs together and don't have PHYs in the
> > middle. There are some boards which do have PHYs, but they don't need
> > any special mode.
> 
> In here there is PHY<->PHY line link. My understanding is that in this
> particular case PHY link works better than *MII links.

I've seen PHY<->PHY done when the switch was on a daughter board, and
there was worries about getting RGMII over the connector etc.

> > So before accepting any patches, we need a better understanding of
> > that reduced MLT-3 is and why you would want to use it.
> 
> OK.
> 
> My understanding is that as we have PHY<->PHY link it needs to handle itself
> in standard way. Thus the MLT-3 full mode is required for communicating with
> Ethernet switch.
> 
> It seems that Texas Instruments has figured out additional power saving
> mechanism by carefully selecting used magnetics (they have guidelines for
> that and list of supported ones). Now the thinking might have continued that
> let's make the power saving mode the default for all.

Do there guidelines for magnetic says anything about what to do when
using unsupported ones. Like turn reduced MLT-3 off?

> With carefully selected magnetics one most likely gets correct looking
> signal when measured from the cable and thus the other party then gets

> I tried to look up what does this class A and class B mean but I am unable
> to find the reasoning for that.

If you look at the oscilloscope screenshots in the support forum, it
looks like in reduced MLT-3 mode, The TX- and TX+ pins only have two
states, not three. It relies on the magnetics to combine the two
signals to produce a three state signal, and handle the bias in each
signal.

When in MLT-3 mode, i expect the TX- and TX+ pins do real MLT-3.

With real MLT-3, you can then do capacitor coupling to other devices
which conform to 802.3.

> Do we have people from Texas Instruments that could share more insights?

Maybe, but don't hold your breath. Since Dan Murphy left TI, TI does
not really support its own PHYs in mainline.

> In a way this could even be:
> 
>   ti,force-standard-mlt-3-signaling;

Maybe. Or ti,disable-proprietary-line-coding

Lets give TI a couple of days to comment.

     Andrew