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

[Madalin Bucur <madalin.bucur@nxp.com>]

> -----Original Message-----
> From: Russell King <linux@armlinux.org.uk>
> Sent: 04 June 2021 23:00
> To: Madalin Bucur <madalin.bucur@nxp.com>
> Cc: Pali Rohár <pali@kernel.org>; Andrew Lunn <andrew@lunn.ch>; Igal
> Liberman <Igal.Liberman@freescale.com>; Shruti Kanetkar
> <Shruti@freescale.com>; Emil Medve <Emilian.Medve@freescale.com>; Scott
> Wood <oss@buserror.net>; Rob Herring <robh+dt@kernel.org>; Michael
> Ellerman <mpe@ellerman.id.au>; Benjamin Herrenschmidt
> <benh@kernel.crashing.org>; netdev@vger.kernel.org;
> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; Camelia
> Alexandra Groza (OSS) <camelia.groza@oss.nxp.com>
> Subject: Re: Unsupported phy-connection-type sgmii-2500 in
> arch/powerpc/boot/dts/fsl/t1023rdb.dts
> 
> On Fri, Jun 04, 2021 at 07:39:10PM +0000, Madalin Bucur wrote:
> > > -----Original Message-----
> > > From: Russell King <linux@armlinux.org.uk>
> > > Sent: 04 June 2021 22:28
> > > To: Madalin Bucur <madalin.bucur@nxp.com>
> > > Cc: Pali Rohár <pali@kernel.org>; Andrew Lunn <andrew@lunn.ch>; Igal
> > > Liberman <Igal.Liberman@freescale.com>; Shruti Kanetkar
> > > <Shruti@freescale.com>; Emil Medve <Emilian.Medve@freescale.com>;
> Scott
> > > Wood <oss@buserror.net>; Rob Herring <robh+dt@kernel.org>; Michael
> > > Ellerman <mpe@ellerman.id.au>; Benjamin Herrenschmidt
> > > <benh@kernel.crashing.org>; netdev@vger.kernel.org;
> > > devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; Camelia
> > > Alexandra Groza (OSS) <camelia.groza@oss.nxp.com>
> > > Subject: Re: Unsupported phy-connection-type sgmii-2500 in
> > > arch/powerpc/boot/dts/fsl/t1023rdb.dts
> > >
> > > On Fri, Jun 04, 2021 at 07:35:33AM +0000, Madalin Bucur wrote:
> > > > 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.
> > > >
> > > > 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.
> > >
> > > Here's the issue though:
> > >
> > > 802.3 defined 1000base-X which is a fixed 1G speed interface using a
> > > 16-bit control word. Implementations of this exist where the control
> > > word can be disabled.
> > >
> > > Cisco came along, took 1000base-X and augmented it to allow speeds of
> > > 10M and 100M by symbol repetition, and changing the format of the
> > > 16-bit control word. Otherwise, it is functionally compatible - indeed
> > > SGMII with the control word disabled will connect with 1000base-X with
> > > the control word disabled. I've done it several times.
> > >
> > > There exists 2500base-X, which is 1000base-X clocked faster, and it
> > > seems the concensus is that it has the AN disabled - in other words,
> > > no control word.
> > >
> > > Now you're saying that SGMII at 2.5G speed exists, which is 1G SGMII
> > > fixed at 1G speed, without a control word, upclocked by 2.5x.
> > >
> > > My question to you is how is how is this SGMII 2.5G different from
> > > 2500base-X?
> > >
> > > > In 2015, when this was submitted,
> > > > there were no other 2.5G compatibles in use, if I'm not mistaken.
> > > > 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.
> > >
> > > My argument has been (since I've had experience of SGMII talking to
> > > 1000base-X, and have also accidentally clocked such a scenario at
> > > 2.5G speeds) that there is in fact no functional difference between
> > > SGMII and base-X when they are running at identical speeds with the
> > > control word disabled.
> > >
> > > Given that we well know that industry likes to use the term "SGMII"
> > > very loosely to mean <whatever>base-X as well as SGMII, it becomes
> > > a very bad term to use when we wish to differentiate between a
> > > base-X and a real Cisco SGMII link with their different control word
> > > formats.
> > >
> > > And this has always been my point - industry has created confusion
> > > over these terms, but as software programmers, we need to know the
> > > difference. So, SGMII should _only_ be used to identify the Cisco
> > > SGMII modified version of 802.3 base-X _with_ the modified control
> > > word or with the capability of symbol repetition. In other words,
> > > the very features that make it SGMII as opposed to 802.3 base-X.
> > > Everything else should not use the term SGMII.
> > >
> > > > 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.
> > >
> > > The "confusion" comes from an abuse of terms. Abused terms really
> > > can't adequately be used to describe hardware properties.
> > >
> > > As I say above, we _know_ that some manufacturers state that their
> > > single lane serdes is "SGMII" when it is in fact 1000base-X. That
> > > doesn't mean we stuff "sgmii" into device tree because that's what
> > > the vendor decided to call it.
> > >
> > > "sgmii" in the device tree means Cisco's well defined SGMII and
> > > does not mean 1000base-X.
> >
> > 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.
> 
> I have given you a detailed explanation of my view on this, which is
> based on reading the 802.3 and Cisco SGMII specifications and various
> device datasheets from multiple different manufacturers.
> 
> I find your argument which seems to be based on what your hardware
> in front of you "does" and the actual explanation of it to be an
> extremely weak response.
> 
> Please provide a robust argument for your position. Thanks.

By lacking AN abilities, this HW fits neither SGMII nor 1000Base-X, leave aside
the speed increment. Other than that, I do not feel I have to justify someone's
decision to not align in 2015 to something that became a habit in 2019, I just
provided an explanation for the information they acted upon.

Regards,
Madalin