linux-kernel - Re: Unsupported phy-connection-type sgmii-2500 in arch/powerpc/boot/dts/fsl/t1023rdb.dts

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:   Sat, 5 Jun 2021 01:33:07 +0100
From:   "Russell King (Oracle)" <linux@...linux.org.uk>
To:     Pali Rohár <pali@...nel.org>
Cc:     Madalin Bucur <madalin.bucur@....com>,
        Andrew Lunn <andrew@...n.ch>,
        Igal Liberman <Igal.Liberman@...escale.com>,
        Shruti Kanetkar <Shruti@...escale.com>,
        Emil Medve <Emilian.Medve@...escale.com>,
        Scott Wood <oss@...error.net>,
        Rob Herring <robh+dt@...nel.org>,
        Michael Ellerman <mpe@...erman.id.au>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Camelia Alexandra Groza (OSS)" <camelia.groza@....nxp.com>
Subject: Re: Unsupported phy-connection-type sgmii-2500 in
 arch/powerpc/boot/dts/fsl/t1023rdb.dts

On Sat, Jun 05, 2021 at 01:34:55AM +0200, Pali Rohár wrote:
> But as this is really confusing what each mode means for Linux, I would
> suggest that documentation for these modes in ethernet-controller.yaml
> file (or in any other location) could be extended. I see that it is
> really hard to find exact information what these modes mean and what is
> their meaning in DTS / kernel.

We have been adding documentation to:

Documentation/networking/phy.rst

for each of the modes that have had issues. The 2500base-X entry
hasn't been updated yet, as the question whether it can have in-band
signaling is unclear (there is no well defined standard for this.)

Some vendors state that there is no in-band signalling in 2500base-X.
Others (e.g. Xilinx) make it clear that it is optional. Others don't
say either way, and when testing hardware, it appears to be functional.

So, coming up with a clear definition for this, when we have no real
method in the DT file to say "definitely do not use in-band" is a tad
difficult.

It started out as described - literally, 1000base-X multiplied by 2.5x.
There are setups where that is known to work - namely GPON SFPs that
support 2500base-X. What that means is that we know the GPON SFP
module negotiates in-band AN with 2500base-X. However, we don't know
whether the module will work if we disable in-band AN.

There is hardware out there as well which allows one to decide whether
to use in-band AN with 2500base-X or not. Xilinx is one such vendor
who explicitly documents this. Marvell on the other hand do not
prohibit in-band AN with mvneta, neither to they explicitly state it
is permitted. In at least one of their PHY documents, they suggest it
isn't supported if the MAC side is operating in 2500base-X.

Others (NXP) take the position that in-band AN is not supported at
2500base-X speeds. I think a few months ago, Vladimir persuaded me
that we should disable in-band AN for 2500base-X - I had forgotten
about the Xilinx documentation I had which shows that it's optional.
(Practically, it's optional in hardware with 1000base-X too, but then
it's not actually conforming with 802.3's definition of 1000base-X.)

The result is, essentially, a total mess. 2500base-X is not a standards
defined thing, so different vendors have gone off and done different
things.

Sometimes it's amazing that you can connect two devices together and
they will actually talk to each other!

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!