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

[Madalin Bucur]

> -----Original Message-----
> From: Pali Rohár <pali@xxxxxxxxxx>
> Sent: 04 June 2021 20:33
> To: Madalin Bucur <madalin.bucur@xxxxxxx>
> Cc: Andrew Lunn <andrew@xxxxxxx>; 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>; Russell King
> <rmk+kernel@xxxxxxxxxxxxxxx>; 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
> 
> Hello!
> 
> On Friday 04 June 2021 07:35:33 Madalin Bucur wrote:
> > > -----Original Message-----
> > > From: Pali Rohár <pali@xxxxxxxxxx>
> > > Sent: 03 June 2021 22:49
> > > To: Andrew Lunn <andrew@xxxxxxx>
> > > Cc: 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>; Madalin Bucur <madalin.bucur@xxxxxxx>;
> Russell
> > > King <rmk+kernel@xxxxxxxxxxxxxxx>; netdev@xxxxxxxxxxxxxxx;
> > > devicetree@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx
> > > Subject: Re: Unsupported phy-connection-type sgmii-2500 in
> > > arch/powerpc/boot/dts/fsl/t1023rdb.dts
> > >
> > > On Thursday 03 June 2021 17:12:31 Andrew Lunn wrote:
> > > > On Thu, Jun 03, 2021 at 04:34:53PM +0200, Pali Rohár wrote:
> > > > > Hello!
> > > > >
> > > > > In commit 84e0f1c13806 ("powerpc/mpc85xx: Add MDIO bus muxing
> support
> > > to
> > > > > the board device tree(s)") was added following DT property into DT
> > > node:
> > > > > arch/powerpc/boot/dts/fsl/t1023rdb.dts fm1mac3: ethernet@e4000
> > > > >
> > > > >     phy-connection-type = "sgmii-2500";
> > > > >
> > > > > But currently kernel does not recognize this "sgmii-2500" phy mode.
> > > See
> > > > > file include/linux/phy.h. In my opinion it should be "2500base-x"
> as
> > > > > this is mode which operates at 2.5 Gbps.
> > > > >
> > > > > I do not think that sgmii-2500 mode exist at all (correct me if
> I'm
> > > > > wrong).
> > > >
> > > > Kind of exist, unofficially. Some vendors run SGMII over clocked at
> > > > 2500. But there is no standard for it, and it is unclear how inband
> > > > signalling should work. Whenever i see code saying 2.5G SGMII, i
> > > > always ask, are you sure, is it really 2500BaseX? Mostly it gets
> > > > changed to 2500BaseX after review.
> > >
> > > So this is question for authors of that commit 84e0f1c13806. But it
> > > looks like I cannot send them emails because of following error:
> > >
> > > <Minghuan.Lian@xxxxxxxxxxxxx>: connect to
> freescale.com[192.88.156.33]:25:
> > > Connection timed out
> > >
> > > Do you have other way how to contact maintainers of that DTS file?
> > > arch/powerpc/boot/dts/fsl/t1023rdb.dts
> > >
> > > > PHY mode sgmii-2500 does not exist in mainline.
> > >
> > > Yes, this is reason why I sent this email. In DTS is specified this
> mode
> > > which does not exist.
> > >
> > > > 	Andrew
> >
> > Hi, the Freescale emails no longer work, years after Freescale joined
> NXP.
> > Also, the first four recipients no longer work for NXP.
> >
> > In regards to the sgmii-2500 you see in the device tree, it describes
> SGMII
> > overclocked to 2.5Gbps, with autonegotiation disabled.
> >
> > A quote from a long time ago, from someone from the HW team on this:
> >
> > 	The industry consensus is that 2.5G SGMII is overclocked 1G SGMII
> > 	using XAUI electricals. For the PCS and MAC layers, it looks exactly
> > 	like 1G SGMII, just with a faster clock.
> 
> SGMII supports 1 Gbps speed and also 100 / 10 Mbps by repeating frame 10
> or 100 times.
> 
> So... if this HW has 2.5G SGMII (sgmii-2500) as 2.5x overclocked SGMII,
> does it mean that 2.5G SGMII supports 25 Mbps and 250 Mbps speeds by
> repeating frame 10 and 100 times (like for 1G SGMII)?

I had the same curiosity at the time - no, it does not support anything
other than 2.5G in this mode, so all that flexibility of SGMII is gone.
It seems it was a HW "hack" of sorts to get more speed.

> > The statement that it does not exist is not accurate, it exists in HW,
> and
> > it is described as such in the device tree. Whether or not it is
> properly
> > treated in SW it's another discussion. In 2015, when this was submitted,
> > there were no other 2.5G compatibles in use, if I'm not mistaken.
> 
> Yea, I understand. If at that time there was no sw support, "something"
> was chosen.
> 
> > 2500Base-X started to be added to device trees four years later, it
> should
> > be compatible/interworking but it is less specific on the actual
> implementation
> > details (denotes 2.5G speed, 8b/10b coding, which is true for this
> overclocked
> > SGMII). If they are compatible, SW should probably treat them in the
> same manner.
> 
> 1000base-x and SGMII are not same modes. E.g. SGMII support 10 Mbps
> while 1000base-x not. So in my opinion 1000base-x and SGMII should not
> be treated as the same mode (in SW).
> 
> I'm not sure how what exactly SGMII-2500 supports, but as 2500base-x
> does not support 25 Mbps speed I do not think that SGMII-2500 is same as
> 2500base-x.

Seems to interoperate though, as PHYs that do not list this SGMII 2500 as
a supported mode work with this overclocked SGMII IP (with SGMII AN disabled).
If this disabling was not required, it could have been declared as SGMII,
(the overclocking is done by the HW config registers). But when the HW runs
in normal SGMII mode, it uses AN, and when configured for this sgmii-2500
it does not use AN, so the driver needs to know about it, to disable AN.
From the networking stack's perspective, it looks like a 2500Base-X device.

> But now I'm totally confused by all these modes, so I hope that somebody
> else tries to explain what kernel expects and how kernel treats these
> modes.
> 
> > There were some discussions a while ago about the mix or even confusion
> between
> > the actual HW description (that's what the dts is supposed to do) and
> the settings
> > one wants to represent in SW (i.e. speed) denoted loosely by
> denominations like
> > 10G Base-R.
> >
> > Regards,
> > Madalin