linux-kernel - 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]

Message-ID: <85e9dfbd-baea-1d73-aaf0-d6c14a1305eb@vaisala.com>
Date:   Tue, 11 Jul 2023 10:51:22 +0300
From:   Vesa Jääskeläinen 
        <vesa.jaaskelainen@...sala.com>
To:     Andrew Lunn <andrew@...n.ch>
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

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.

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

>> In the connection there there is no Ethernet cable at all but routes
>> within the circuit boards but instead has capacitive coupling on routes.
> So you also left out the magnetics?

Yes for this chip-to-chip link.

>> So the setting itself is related to specific circuit board design.
> Agreed. So it is then valid to put it into DT, if it is actually
> needed.
>
>> MLT-3 is related to encoding used in the signals -- I suppose wiki page is
>> good introduction reference:
>>
>> https://en.wikipedia.org/wiki/MLT-3_encoding
> MLT-3 is well defined. What i could not find is any reference to what
> reduced MLT-3 is. If it is not part of any standard, why don't you
> just hard code the PHY to always use MTL-3 which is defined as part of
> 802.3?
>
> I get the feeling reduced MLT-3 is TI proprietary. As such, it should
> default to MLT-3 as defined in 802.3 and there could then be an option
> to enable this proprietary mode for anybody we wants to use it.
>
> 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.

With carefully selected magnetics one most likely gets correct looking 
signal when measured from the cable and thus the other party then gets 
properly looking signal. I suppose this is the majority of the users.

Now what can be the default operation.

My thinking was that let's keep current functionality as is so that 
no-one would get surprises with it -- and it is default setting for the 
chip too.

Then again there has been also others like one in TI's e2e forum that 
already had problems by not having the MLT-3 full mode enabled so 
default could even be MLT-3 full and then have extra device tree setting 
to enable this power saving feature. But then again one does not benefit 
from power saving features developed by chip manufactures if we by 
default try to cancel the effect. And this cancelling most likely would 
happen afterwards of the original driver implementation as these are in 
special registers.

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

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

In a way this could even be:

   ti,force-standard-mlt-3-signaling;

Then there is no ambiguity what it does.

Thanks,
Vesa Jääskeläinen