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

[Pali Rohár]

On Saturday 05 June 2021 01:34:55 Pali Rohár wrote:
> 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?

Any opinion? Or should I send a patch?