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

[Pali Rohár]

On Friday 04 June 2021 21:47:26 Madalin Bucur wrote:
> > -----Original Message-----
> > From: Andrew Lunn <andrew@xxxxxxx>
> > Sent: 04 June 2021 23:24
> > To: Madalin Bucur <madalin.bucur@xxxxxxx>
> > Cc: Russell King <linux@xxxxxxxxxxxxxxx>; Pali Rohár <pali@xxxxxxxxxx>;
> > Igal Liberman <Igal.Liberman@xxxxxxxxxxxxx>; Shruti Kanetkar
> > <Shruti@xxxxxxxxxxxxx>; Emil Medve <Emilian.Medve@xxxxxxxxxxxxx>; Scott
> > Wood <oss@xxxxxxxxxxxx>; Rob Herring <robh+dt@xxxxxxxxxx>; Michael
> > Ellerman <mpe@xxxxxxxxxxxxxx>; Benjamin Herrenschmidt
> > <benh@xxxxxxxxxxxxxxxxxxx>; netdev@xxxxxxxxxxxxxxx;
> > devicetree@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; Camelia
> > Alexandra Groza (OSS) <camelia.groza@xxxxxxxxxxx>
> > Subject: Re: Unsupported phy-connection-type sgmii-2500 in
> > arch/powerpc/boot/dts/fsl/t1023rdb.dts
> > 
> > > The "sgmii-2500" compatible in that device tree describes an SGMII HW
> > > block, overclocked at 2.5G. Without that overclocking, it's a plain
> > > Cisco (like) SGMII HW block. That's the reason you need to disable it's
> > > AN setting when overclocked. With the proper Reset Configuration Word,
> > > you could remove the overclocking and transform that into a plain
> > "sgmii".
> > > Thus, the dts compatible describes the HW, as it is.
> > 
> > It sounds like the hardware is capable of swapping between SGMII and
> > 2500BaseX.
> > 
> > What we have in DT in this case is not describing the hardware, but
> > how we configure the hardware. It is one of the few places we abuse DT
> > for configuration.
> > 
> >     Andrew
> 
> The actual selection of this mode of operation is performed by the so called
> Reset Configuration Word from the boot media, that aligned with the HW and
> board design. The need to name it something other than plain "sgmii" comes
> from the HW special need for AN to be disabled to operate.
> 
> Actually, the weird/non-standard hardware is described by the device tree
> with a value that puts it in a class of its own. Instead of the overclocked
> SGMII denomination "sgmii-2500" it could have been named just as well
> "overclocked-nonstandard-2.5G-ethernet-no-autoneg-SGMII-hw-ip".
> 
> One could try to change device trees to slip configuration details, but the
> backwards compatibility aspect renders this futile. Is there any option to
> say "sgmii" then "autoneg disabled"?
> 
> Madalin

Madalin, my understanding is that "sgmii-2500" mode is unknown and
unsupported by kernel.

List of known modes which can be specified in DTS file are defined in
YAML schema for 'phy-connection-type' in file:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/net/ethernet-controller.yaml?h=v5.12#n55

And there is none "sgmii-2500", so some DTS schema validator could throw
validation error for that DTS file. I'm not sure if somebody has written
DTS schema validator with all those things (like there are JSON schema
or OpenAPI validators in JavaScript / HTTP world).

Plus also in linux/phy.h header file contains list of known Linux modes:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/phy.h?h=v5.12#n169

And based on all information in this email discussion, in my opinion the
mode which HW supports matches Linux meaning of "2500base-x" key/string.
So I would suggest to rename "sgmii-2500" in that DTS file to
"2500base-x". Does it make sense?



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.