All of lore.kernel.org
 help / color / mirror / Atom feed
* Unsupported phy-connection-type sgmii-2500 in arch/powerpc/boot/dts/fsl/t1023rdb.dts
@ 2021-06-03 14:34 Pali Rohár
  2021-06-03 15:12 ` Andrew Lunn
  0 siblings, 1 reply; 29+ messages in thread
From: Pali Rohár @ 2021-06-03 14:34 UTC (permalink / raw)
  To: Igal Liberman, Shruti Kanetkar, Emil Medve, Scott Wood
  Cc: Rob Herring, Michael Ellerman, Benjamin Herrenschmidt,
	Madalin Bucur, Andrew Lunn, Russell King, netdev, devicetree,
	linux-kernel

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).

Could you look at this DT property issue? What should be filled here?

I'm CCing netdev and other developers as I see that there is lot of
times confusion between sgmii, 1000base-x and 2500base-x modes.

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Unsupported phy-connection-type sgmii-2500 in arch/powerpc/boot/dts/fsl/t1023rdb.dts
  2021-06-03 14:34 Unsupported phy-connection-type sgmii-2500 in arch/powerpc/boot/dts/fsl/t1023rdb.dts Pali Rohár
@ 2021-06-03 15:12 ` Andrew Lunn
  2021-06-03 19:48   ` Pali Rohár
  0 siblings, 1 reply; 29+ messages in thread
From: Andrew Lunn @ 2021-06-03 15:12 UTC (permalink / raw)
  To: Pali Rohár
  Cc: Igal Liberman, Shruti Kanetkar, Emil Medve, Scott Wood,
	Rob Herring, Michael Ellerman, Benjamin Herrenschmidt,
	Madalin Bucur, Russell King, netdev, devicetree, linux-kernel

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.

PHY mode sgmii-2500 does not exist in mainline.

	Andrew


^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Unsupported phy-connection-type sgmii-2500 in arch/powerpc/boot/dts/fsl/t1023rdb.dts
  2021-06-03 15:12 ` Andrew Lunn
@ 2021-06-03 19:48   ` Pali Rohár
  2021-06-04  7:35     ` Madalin Bucur
  0 siblings, 1 reply; 29+ messages in thread
From: Pali Rohár @ 2021-06-03 19:48 UTC (permalink / raw)
  To: Andrew Lunn
  Cc: Igal Liberman, Shruti Kanetkar, Emil Medve, Scott Wood,
	Rob Herring, Michael Ellerman, Benjamin Herrenschmidt,
	Madalin Bucur, Russell King, netdev, devicetree, linux-kernel

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@freescale.com>: 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
> 

^ permalink raw reply	[flat|nested] 29+ messages in thread

* RE: Unsupported phy-connection-type sgmii-2500 in arch/powerpc/boot/dts/fsl/t1023rdb.dts
  2021-06-03 19:48   ` Pali Rohár
@ 2021-06-04  7:35     ` Madalin Bucur
  2021-06-04 17:32       ` Pali Rohár
  2021-06-04 19:27       ` Russell King (Oracle)
  0 siblings, 2 replies; 29+ messages in thread
From: Madalin Bucur @ 2021-06-04  7:35 UTC (permalink / raw)
  To: Pali Rohár, Andrew Lunn
  Cc: Igal Liberman, Shruti Kanetkar, Emil Medve, Scott Wood,
	Rob Herring, Michael Ellerman, Benjamin Herrenschmidt,
	Russell King, netdev, devicetree, linux-kernel,
	Camelia Alexandra Groza (OSS)

> -----Original Message-----
> From: Pali Rohár <pali@kernel.org>
> Sent: 03 June 2021 22:49
> To: Andrew Lunn <andrew@lunn.ch>
> Cc: 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>; Madalin Bucur <madalin.bucur@nxp.com>; Russell
> King <rmk+kernel@armlinux.org.uk>; netdev@vger.kernel.org;
> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org
> 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@freescale.com>: 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.

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.
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.

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

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Unsupported phy-connection-type sgmii-2500 in arch/powerpc/boot/dts/fsl/t1023rdb.dts
  2021-06-04  7:35     ` Madalin Bucur
@ 2021-06-04 17:32       ` Pali Rohár
  2021-06-04 19:13         ` Madalin Bucur
  2021-06-04 19:27       ` Russell King (Oracle)
  1 sibling, 1 reply; 29+ messages in thread
From: Pali Rohár @ 2021-06-04 17:32 UTC (permalink / raw)
  To: Madalin Bucur
  Cc: Andrew Lunn, Igal Liberman, Shruti Kanetkar, Emil Medve,
	Scott Wood, Rob Herring, Michael Ellerman,
	Benjamin Herrenschmidt, Russell King, netdev, devicetree,
	linux-kernel, Camelia Alexandra Groza (OSS)

Hello!

On Friday 04 June 2021 07:35:33 Madalin Bucur wrote:
> > -----Original Message-----
> > From: Pali Rohár <pali@kernel.org>
> > Sent: 03 June 2021 22:49
> > To: Andrew Lunn <andrew@lunn.ch>
> > Cc: 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>; Madalin Bucur <madalin.bucur@nxp.com>; Russell
> > King <rmk+kernel@armlinux.org.uk>; netdev@vger.kernel.org;
> > devicetree@vger.kernel.org; linux-kernel@vger.kernel.org
> > 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@freescale.com>: 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)?

> 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.

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

^ permalink raw reply	[flat|nested] 29+ messages in thread

* RE: Unsupported phy-connection-type sgmii-2500 in arch/powerpc/boot/dts/fsl/t1023rdb.dts
  2021-06-04 17:32       ` Pali Rohár
@ 2021-06-04 19:13         ` Madalin Bucur
  0 siblings, 0 replies; 29+ messages in thread
From: Madalin Bucur @ 2021-06-04 19:13 UTC (permalink / raw)
  To: Pali Rohár
  Cc: Andrew Lunn, Scott Wood, Rob Herring, Michael Ellerman,
	Benjamin Herrenschmidt, Russell King, netdev, devicetree,
	linux-kernel, Camelia Alexandra Groza (OSS)

> -----Original Message-----
> From: Pali Rohár <pali@kernel.org>
> Sent: 04 June 2021 20:33
> To: Madalin Bucur <madalin.bucur@nxp.com>
> Cc: 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>; Russell King
> <rmk+kernel@armlinux.org.uk>; 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
> 
> Hello!
> 
> On Friday 04 June 2021 07:35:33 Madalin Bucur wrote:
> > > -----Original Message-----
> > > From: Pali Rohár <pali@kernel.org>
> > > Sent: 03 June 2021 22:49
> > > To: Andrew Lunn <andrew@lunn.ch>
> > > Cc: 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>; Madalin Bucur <madalin.bucur@nxp.com>;
> Russell
> > > King <rmk+kernel@armlinux.org.uk>; netdev@vger.kernel.org;
> > > devicetree@vger.kernel.org; linux-kernel@vger.kernel.org
> > > 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@freescale.com>: 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

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Unsupported phy-connection-type sgmii-2500 in arch/powerpc/boot/dts/fsl/t1023rdb.dts
  2021-06-04  7:35     ` Madalin Bucur
  2021-06-04 17:32       ` Pali Rohár
@ 2021-06-04 19:27       ` Russell King (Oracle)
  2021-06-04 19:39         ` Madalin Bucur
  2021-06-04 23:18         ` Unsupported phy-connection-type sgmii-2500 in arch/powerpc/boot/dts/fsl/t1023rdb.dts Pali Rohár
  1 sibling, 2 replies; 29+ messages in thread
From: Russell King (Oracle) @ 2021-06-04 19:27 UTC (permalink / raw)
  To: Madalin Bucur
  Cc: Pali Rohár, Andrew Lunn, Igal Liberman, Shruti Kanetkar,
	Emil Medve, Scott Wood, Rob Herring, Michael Ellerman,
	Benjamin Herrenschmidt, netdev, devicetree, linux-kernel,
	Camelia Alexandra Groza (OSS)

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.

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

^ permalink raw reply	[flat|nested] 29+ messages in thread

* RE: Unsupported phy-connection-type sgmii-2500 in arch/powerpc/boot/dts/fsl/t1023rdb.dts
  2021-06-04 19:27       ` Russell King (Oracle)
@ 2021-06-04 19:39         ` Madalin Bucur
  2021-06-04 20:00           ` Russell King (Oracle)
  2021-06-04 20:23           ` Andrew Lunn
  2021-06-04 23:18         ` Unsupported phy-connection-type sgmii-2500 in arch/powerpc/boot/dts/fsl/t1023rdb.dts Pali Rohár
  1 sibling, 2 replies; 29+ messages in thread
From: Madalin Bucur @ 2021-06-04 19:39 UTC (permalink / raw)
  To: Russell King
  Cc: Pali Rohár, Andrew Lunn, Igal Liberman, Shruti Kanetkar,
	Emil Medve, Scott Wood, Rob Herring, Michael Ellerman,
	Benjamin Herrenschmidt, netdev, devicetree, linux-kernel,
	Camelia Alexandra Groza (OSS)

> -----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.

Madalin



^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Unsupported phy-connection-type sgmii-2500 in arch/powerpc/boot/dts/fsl/t1023rdb.dts
  2021-06-04 19:39         ` Madalin Bucur
@ 2021-06-04 20:00           ` Russell King (Oracle)
  2021-06-04 21:37             ` Madalin Bucur
  2021-06-04 20:23           ` Andrew Lunn
  1 sibling, 1 reply; 29+ messages in thread
From: Russell King (Oracle) @ 2021-06-04 20:00 UTC (permalink / raw)
  To: Madalin Bucur
  Cc: Pali Rohár, Andrew Lunn, Igal Liberman, Shruti Kanetkar,
	Emil Medve, Scott Wood, Rob Herring, Michael Ellerman,
	Benjamin Herrenschmidt, netdev, devicetree, linux-kernel,
	Camelia Alexandra Groza (OSS)

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.

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

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Unsupported phy-connection-type sgmii-2500 in arch/powerpc/boot/dts/fsl/t1023rdb.dts
  2021-06-04 19:39         ` Madalin Bucur
  2021-06-04 20:00           ` Russell King (Oracle)
@ 2021-06-04 20:23           ` Andrew Lunn
  2021-06-04 21:47             ` Madalin Bucur
  1 sibling, 1 reply; 29+ messages in thread
From: Andrew Lunn @ 2021-06-04 20:23 UTC (permalink / raw)
  To: Madalin Bucur
  Cc: Russell King, Pali Rohár, Igal Liberman, Shruti Kanetkar,
	Emil Medve, Scott Wood, Rob Herring, Michael Ellerman,
	Benjamin Herrenschmidt, netdev, devicetree, linux-kernel,
	Camelia Alexandra Groza (OSS)

> 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

^ permalink raw reply	[flat|nested] 29+ messages in thread

* RE: Unsupported phy-connection-type sgmii-2500 in arch/powerpc/boot/dts/fsl/t1023rdb.dts
  2021-06-04 20:00           ` Russell King (Oracle)
@ 2021-06-04 21:37             ` Madalin Bucur
  0 siblings, 0 replies; 29+ messages in thread
From: Madalin Bucur @ 2021-06-04 21:37 UTC (permalink / raw)
  To: Russell King
  Cc: Pali Rohár, Andrew Lunn, Igal Liberman, Shruti Kanetkar,
	Emil Medve, Scott Wood, Rob Herring, Michael Ellerman,
	Benjamin Herrenschmidt, netdev, devicetree, linux-kernel,
	Camelia Alexandra Groza (OSS)

> -----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

^ permalink raw reply	[flat|nested] 29+ messages in thread

* RE: Unsupported phy-connection-type sgmii-2500 in arch/powerpc/boot/dts/fsl/t1023rdb.dts
  2021-06-04 20:23           ` Andrew Lunn
@ 2021-06-04 21:47             ` Madalin Bucur
  2021-06-04 23:34               ` Pali Rohár
  0 siblings, 1 reply; 29+ messages in thread
From: Madalin Bucur @ 2021-06-04 21:47 UTC (permalink / raw)
  To: Andrew Lunn
  Cc: Russell King, Pali Rohár, Igal Liberman, Shruti Kanetkar,
	Emil Medve, Scott Wood, Rob Herring, Michael Ellerman,
	Benjamin Herrenschmidt, netdev, devicetree, linux-kernel,
	Camelia Alexandra Groza (OSS)

> -----Original Message-----
> From: Andrew Lunn <andrew@lunn.ch>
> Sent: 04 June 2021 23:24
> To: Madalin Bucur <madalin.bucur@nxp.com>
> Cc: Russell King <linux@armlinux.org.uk>; Pali Rohár <pali@kernel.org>;
> 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
> 
> > 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

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Unsupported phy-connection-type sgmii-2500 in arch/powerpc/boot/dts/fsl/t1023rdb.dts
  2021-06-04 19:27       ` Russell King (Oracle)
  2021-06-04 19:39         ` Madalin Bucur
@ 2021-06-04 23:18         ` Pali Rohár
  1 sibling, 0 replies; 29+ messages in thread
From: Pali Rohár @ 2021-06-04 23:18 UTC (permalink / raw)
  To: Russell King (Oracle)
  Cc: Madalin Bucur, Andrew Lunn, Igal Liberman, Shruti Kanetkar,
	Emil Medve, Scott Wood, Rob Herring, Michael Ellerman,
	Benjamin Herrenschmidt, netdev, devicetree, linux-kernel,
	Camelia Alexandra Groza (OSS)

On Friday 04 June 2021 20:27:33 Russell King (Oracle) wrote:
> 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.

Thank you for a nice explanation! I think that this information should
be part of documentation as it could help also other people to
understand differences between these modes.

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Unsupported phy-connection-type sgmii-2500 in arch/powerpc/boot/dts/fsl/t1023rdb.dts
  2021-06-04 21:47             ` Madalin Bucur
@ 2021-06-04 23:34               ` Pali Rohár
  2021-06-05  0:33                 ` Russell King (Oracle)
                                   ` (2 more replies)
  0 siblings, 3 replies; 29+ messages in thread
From: Pali Rohár @ 2021-06-04 23:34 UTC (permalink / raw)
  To: Madalin Bucur
  Cc: Andrew Lunn, Russell King, Igal Liberman, Shruti Kanetkar,
	Emil Medve, Scott Wood, Rob Herring, Michael Ellerman,
	Benjamin Herrenschmidt, netdev, devicetree, linux-kernel,
	Camelia Alexandra Groza (OSS)

On Friday 04 June 2021 21:47:26 Madalin Bucur wrote:
> > -----Original Message-----
> > From: Andrew Lunn <andrew@lunn.ch>
> > Sent: 04 June 2021 23:24
> > To: Madalin Bucur <madalin.bucur@nxp.com>
> > Cc: Russell King <linux@armlinux.org.uk>; Pali Rohár <pali@kernel.org>;
> > 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
> > 
> > > 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.

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Unsupported phy-connection-type sgmii-2500 in arch/powerpc/boot/dts/fsl/t1023rdb.dts
  2021-06-04 23:34               ` Pali Rohár
@ 2021-06-05  0:33                 ` Russell King (Oracle)
  2021-06-05 12:26                   ` Vladimir Oltean
  2021-06-19 20:35                 ` Unsupported phy-connection-type sgmii-2500 in arch/powerpc/boot/dts/fsl/t1023rdb.dts Pali Rohár
  2021-07-04 13:43                 ` [PATCH] powerpc/fsl/dts: Fix phy-connection-type for fm1mac3 Pali Rohár
  2 siblings, 1 reply; 29+ messages in thread
From: Russell King (Oracle) @ 2021-06-05  0:33 UTC (permalink / raw)
  To: Pali Rohár
  Cc: Madalin Bucur, Andrew Lunn, Igal Liberman, Shruti Kanetkar,
	Emil Medve, Scott Wood, Rob Herring, Michael Ellerman,
	Benjamin Herrenschmidt, netdev, devicetree, linux-kernel,
	Camelia Alexandra Groza (OSS)

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!

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Unsupported phy-connection-type sgmii-2500 in arch/powerpc/boot/dts/fsl/t1023rdb.dts
  2021-06-05  0:33                 ` Russell King (Oracle)
@ 2021-06-05 12:26                   ` Vladimir Oltean
  2021-06-05 12:50                     ` What is inside GPON SFP module? (Was: Re: Unsupported phy-connection-type sgmii-2500 in arch/powerpc/boot/dts/fsl/t1023rdb.dts) Pali Rohár
  0 siblings, 1 reply; 29+ messages in thread
From: Vladimir Oltean @ 2021-06-05 12:26 UTC (permalink / raw)
  To: Russell King (Oracle)
  Cc: Pali Rohár, Madalin Bucur, Andrew Lunn, Igal Liberman,
	Shruti Kanetkar, Emil Medve, Scott Wood, Rob Herring,
	Michael Ellerman, Benjamin Herrenschmidt, netdev, devicetree,
	linux-kernel, Camelia Alexandra Groza (OSS)

On Sat, Jun 05, 2021 at 01:33:07AM +0100, Russell King (Oracle) wrote:
> 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.

If you use phylink, doesn't the lack of
	managed = "in-band-status";
mean "definitely do not use in-band"?

> 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.

Pardon my ignorance, but what is inside a GPON ONT module? Just a laser
and some amplifiers? So it would still be the MAC PCS negotiating flow
control with the remote link partner? That's a different use case from a
PHY transmitting the negotiated link modes to the MAC.

> 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.)

I don't think it is me who persuaded you, but rather the reality exposed
by Marek Behun that the Marvell switches and PHYs don't support clause
37 in-band AN either, at least when connected to one another, just the
mvneta appears to do something with the GPON modules:

https://lore.kernel.org/netdev/20210113011823.3e407b31@kernel.org/

I tend to agree, though. We should prevent in-band AN from being
requested on implementations where we know it will not work. That
includes any NXP products. In the case of DPAA1, this uses the same PCS
block as DPAA2, ENETC, Felix and Seville, so if it were to use phylink
and the common drivers/net/pcs/pcs-lynx.c driver, then the comment near
the lynx_pcs_link_up_2500basex() function would equally apply to it too
(I hope this answers Pali's original question).

> 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.

Correct, I can not find any document mentioning what 2500base-x is either,
while I can find documents mentioning SGMII at 2500Mbps.
https://patents.google.com/patent/US7356047B1/en

This Cisco patent does say a few things, like the fact that the link for
10/100/1000/2500 SGMII should operate at 3.125 Gbaud, and there should
be a rate adaptation unit separate from the PCS block, which should
split a frame into 2 segments, and say for 1Gbps, the first segment
should have its octets repeated twice, and the second segment should
have its octets repeated 3 times.

This patent also does _not_ say how the in-band autonegotiation code
word should be adapted to switch between 10/100/1000/2500. Which makes
the whole patent kind of useless as the basis for a standard for real
life products.

NXP does _not_ follow that patent (we cannot perform symbol replication
in that way, and in fact I would be surprised if anyone does, given the
lack of a way to negotiate between them), and with the limited knowledge
I currently have, that is the only thing I would call "SGMII-2500".
So Cisco "SGMII-2500" does in theory exist, but in practice it is a bit
mythical given what is currently public knowledge.

By the "genus proximum et differentia specifica" criterion, what we have
according to Linux terminology is 2500base-x (whatever that might be, we
at least know the baud rate and the coding scheme) without in-band AN.
We don't seem to have any characteristic that would make the "genus
proximum" be Cisco SGMII (i.e. we can't operate at any other speeds via
symbol replication). But that is ok given the actual use, for example
we achieve the lower speeds using PAUSE frames sent by the PHY.

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

This is not so surprising to me, if you consider the fact that these
devices were built to common sense specs communicated over email between
engineers at different companies. There aren't really that many
companies building these things. The fact that the standards bodies
haven't kept up and unified the implementations is a different story.

I can agree that the chosen name is confusing. What it is is an overclocked
serial GMII (in the sense that it is intended as a MAC-to-PHY link),
with no intended relation to Cisco SGMII. Being intended as a MAC-to-PHY
link, clause 37 AN does not make sense because flow control is 100%
managed by the PHY (negotiated over the copper side, as well as used for
rate adaptation). So there _is_ some merit in calling it something with
"serial" and "GMII" in the name, it is just describing what it is.
Using this interface type over a PHY-less fiber SFP+ module (therefore
using it to its BASE-X name) works by virtue of the fact that the
signaling/coding is compatible, but it wasn't intended that way,
otherwise it would have had support for clause 37 flow control resolution.

^ permalink raw reply	[flat|nested] 29+ messages in thread

* What is inside GPON SFP module? (Was: Re: Unsupported phy-connection-type sgmii-2500 in arch/powerpc/boot/dts/fsl/t1023rdb.dts)
  2021-06-05 12:26                   ` Vladimir Oltean
@ 2021-06-05 12:50                     ` Pali Rohár
  2021-06-05 13:04                       ` Hauke Mehrtens
  0 siblings, 1 reply; 29+ messages in thread
From: Pali Rohár @ 2021-06-05 12:50 UTC (permalink / raw)
  To: Vladimir Oltean
  Cc: Russell King (Oracle),
	Madalin Bucur, Andrew Lunn, Igal Liberman, Shruti Kanetkar,
	Emil Medve, Scott Wood, Rob Herring, Michael Ellerman,
	Benjamin Herrenschmidt, netdev, devicetree, linux-kernel,
	Camelia Alexandra Groza (OSS)

On Saturday 05 June 2021 15:26:39 Vladimir Oltean wrote:
> On Sat, Jun 05, 2021 at 01:33:07AM +0100, Russell King (Oracle) wrote:
> > 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.
> 
> Pardon my ignorance, but what is inside a GPON ONT module? Just a laser
> and some amplifiers? So it would still be the MAC PCS negotiating flow
> control with the remote link partner? That's a different use case from a
> PHY transmitting the negotiated link modes to the MAC.

Hello Vladimir! All GPON ONU/ONT SFP modules which I have tested, are
fully featured mini computers. It is some SoC with powerful CPU, fiber
part, at least two NICs and then two phys, one for fiber part and one
for "SFP"-part (in most cases 1000base-x or 2500base-x). On SoC inside
is running fully featured operating system, in most cases Linux kernel
2.6.3x and tons of userspace applications which implements "application"
layer of GPON protocol -- the most important part. If OEM vendor of GPON
SFP stick did not locked it, you can connect to this "computer" via
telnet or web browser and configure some settings, including GPON stuff
and also how GPON network is connected to SFP part -- e.g. it can be
fully featured IPv4 router with NAT or just plain bridge mode where
"ethernet data packets" (those which are not part of ISP configuration
protocol) are pass-throw to SFP phy 1000base-x to host CPU. GPON is not
ethernet, it is some incompatible and heavily layered extension on ATM.
Originally I thought that ATM is long ago dead (as I saw it in used last
time in ADSL2) but it is still alive and cause issues... I think it does
not use 8b/10b encoding and therefore cannot be directly mapped to
1000base-x. Also GPON uses different wavelengths for inbound and
outbound traffic. And to make it even more complicated it uses totally
nonstandard asynchronous speeds, inbound is 2488.32Mbit/s, outbound is
1244.16Mbit/s. So I guess CPU/SoC with GPON support (something which is
inside that GPON ONU/ONT stick) must use totally different modes for
which we do not have any option in DTS yet.

So once mainline kernel will support these "computers" with GPON support
it would be required to define new kind of phy modes... But I do not
think it happens and all OEM vendors are using 2.6.3x kernels their
userspace GPON implementation is closed has tons of secrets.

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: What is inside GPON SFP module? (Was: Re: Unsupported phy-connection-type sgmii-2500 in arch/powerpc/boot/dts/fsl/t1023rdb.dts)
  2021-06-05 12:50                     ` What is inside GPON SFP module? (Was: Re: Unsupported phy-connection-type sgmii-2500 in arch/powerpc/boot/dts/fsl/t1023rdb.dts) Pali Rohár
@ 2021-06-05 13:04                       ` Hauke Mehrtens
  2021-06-05 13:31                         ` What is inside GPON SFP module? Pali Rohár
  2021-06-05 14:41                         ` What is inside GPON SFP module? (Was: Re: Unsupported phy-connection-type sgmii-2500 in arch/powerpc/boot/dts/fsl/t1023rdb.dts) Russell King (Oracle)
  0 siblings, 2 replies; 29+ messages in thread
From: Hauke Mehrtens @ 2021-06-05 13:04 UTC (permalink / raw)
  To: Pali Rohár, Vladimir Oltean
  Cc: Russell King (Oracle),
	Madalin Bucur, Andrew Lunn, Igal Liberman, Shruti Kanetkar,
	Emil Medve, Scott Wood, Rob Herring, Michael Ellerman,
	Benjamin Herrenschmidt, netdev, devicetree, linux-kernel,
	Camelia Alexandra Groza (OSS)


[-- Attachment #1.1.1: Type: text/plain, Size: 3705 bytes --]

On 6/5/21 2:50 PM, Pali Rohár wrote:
> On Saturday 05 June 2021 15:26:39 Vladimir Oltean wrote:
>> On Sat, Jun 05, 2021 at 01:33:07AM +0100, Russell King (Oracle) wrote:
>>> 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.
>>
>> Pardon my ignorance, but what is inside a GPON ONT module? Just a laser
>> and some amplifiers? So it would still be the MAC PCS negotiating flow
>> control with the remote link partner? That's a different use case from 
a
>> PHY transmitting the negotiated link modes to the MAC.
> 
> Hello Vladimir! All GPON ONU/ONT SFP modules which I have tested, are
> fully featured mini computers. It is some SoC with powerful CPU, fiber
> part, at least two NICs and then two phys, one for fiber part and one
> for "SFP"-part (in most cases 1000base-x or 2500base-x). On SoC inside
> is running fully featured operating system, in most cases Linux kernel
> 2.6.3x and tons of userspace applications which implements "application"
> layer of GPON protocol -- the most important part. If OEM vendor of GPON
> SFP stick did not locked it, you can connect to this "computer" via
> telnet or web browser and configure some settings, including GPON stuff
> and also how GPON network is connected to SFP part -- e.g. it can be
> fully featured IPv4 router with NAT or just plain bridge mode where
> "ethernet data packets" (those which are not part of ISP configuration
> protocol) are pass-throw to SFP phy 1000base-x to host CPU. GPON is not
> ethernet, it is some incompatible and heavily layered extension on ATM.
> Originally I thought that ATM is long ago dead (as I saw it in used last
> time in ADSL2) but it is still alive and cause issues... I think it does
> not use 8b/10b encoding and therefore cannot be directly mapped to
> 1000base-x. Also GPON uses different wavelengths for inbound and
> outbound traffic. And to make it even more complicated it uses totally
> nonstandard asynchronous speeds, inbound is 2488.32Mbit/s, outbound is
> 1244.16Mbit/s. So I guess CPU/SoC with GPON support (something which is
> inside that GPON ONU/ONT stick) must use totally different modes for
> which we do not have any option in DTS yet.
> 
> So once mainline kernel will support these "computers" with GPON support
> it would be required to define new kind of phy modes... But I do not
> think it happens and all OEM vendors are using 2.6.3x kernels their
> userspace GPON implementation is closed has tons of secrets.
> 

Hi,

This description of the GPON SFP sticks is correct, but it misses some 
of the complexity. ;-) GPON is also a shared medium like DOCSIS, you can 
not always send, but you have to wait till you get your time slice over 
PLOAM.
In addition the GPON SFP stick also have to talk the OMCI protocol which 
allows to operator to configure all sorts of layer 2 things. They can 
also login to your SFP stick. ;-)
There are also some passive GPON SFP sticks which just translate between 
electrical and optical signals, but to operate them you need a GPON MAC 
and managed layer on your host.

Adding GPON support properly into Linux is not an easy task, Linux would 
probably need a subsystem with a complexity compared to cfg80211 + hostapd.

Is there a list of things these GPON sticks running Linux should do 
better in the future? For example what to avoid in the EEPROM emulation 
handling?

Hauke

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 10027 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: What is inside GPON SFP module?
  2021-06-05 13:04                       ` Hauke Mehrtens
@ 2021-06-05 13:31                         ` Pali Rohár
  2021-06-05 14:17                           ` Hauke Mehrtens
  2021-06-05 14:41                         ` What is inside GPON SFP module? (Was: Re: Unsupported phy-connection-type sgmii-2500 in arch/powerpc/boot/dts/fsl/t1023rdb.dts) Russell King (Oracle)
  1 sibling, 1 reply; 29+ messages in thread
From: Pali Rohár @ 2021-06-05 13:31 UTC (permalink / raw)
  To: Hauke Mehrtens
  Cc: Vladimir Oltean, Russell King (Oracle),
	Madalin Bucur, Andrew Lunn, Igal Liberman, Shruti Kanetkar,
	Emil Medve, Scott Wood, Rob Herring, Michael Ellerman,
	Benjamin Herrenschmidt, netdev, devicetree, linux-kernel,
	Camelia Alexandra Groza (OSS)

On Saturday 05 June 2021 15:04:55 Hauke Mehrtens wrote:
> On 6/5/21 2:50 PM, Pali Rohár wrote:
> > On Saturday 05 June 2021 15:26:39 Vladimir Oltean wrote:
> > > On Sat, Jun 05, 2021 at 01:33:07AM +0100, Russell King (Oracle) wrote:
> > > > 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.
> > > 
> > > Pardon my ignorance, but what is inside a GPON ONT module? Just a laser
> > > and some amplifiers? So it would still be the MAC PCS negotiating flow
> > > control with the remote link partner? That's a different use case
> > > from
> a
> > > PHY transmitting the negotiated link modes to the MAC.
> > 
> > Hello Vladimir! All GPON ONU/ONT SFP modules which I have tested, are
> > fully featured mini computers. It is some SoC with powerful CPU, fiber
> > part, at least two NICs and then two phys, one for fiber part and one
> > for "SFP"-part (in most cases 1000base-x or 2500base-x). On SoC inside
> > is running fully featured operating system, in most cases Linux kernel
> > 2.6.3x and tons of userspace applications which implements "application"
> > layer of GPON protocol -- the most important part. If OEM vendor of GPON
> > SFP stick did not locked it, you can connect to this "computer" via
> > telnet or web browser and configure some settings, including GPON stuff
> > and also how GPON network is connected to SFP part -- e.g. it can be
> > fully featured IPv4 router with NAT or just plain bridge mode where
> > "ethernet data packets" (those which are not part of ISP configuration
> > protocol) are pass-throw to SFP phy 1000base-x to host CPU. GPON is not
> > ethernet, it is some incompatible and heavily layered extension on ATM.
> > Originally I thought that ATM is long ago dead (as I saw it in used last
> > time in ADSL2) but it is still alive and cause issues... I think it does
> > not use 8b/10b encoding and therefore cannot be directly mapped to
> > 1000base-x. Also GPON uses different wavelengths for inbound and
> > outbound traffic. And to make it even more complicated it uses totally
> > nonstandard asynchronous speeds, inbound is 2488.32Mbit/s, outbound is
> > 1244.16Mbit/s. So I guess CPU/SoC with GPON support (something which is
> > inside that GPON ONU/ONT stick) must use totally different modes for
> > which we do not have any option in DTS yet.
> > 
> > So once mainline kernel will support these "computers" with GPON support
> > it would be required to define new kind of phy modes... But I do not
> > think it happens and all OEM vendors are using 2.6.3x kernels their
> > userspace GPON implementation is closed has tons of secrets.
> > 
> 
> Hi,
> 
> This description of the GPON SFP sticks is correct, but it misses some of
> the complexity. ;-) GPON is also a shared medium like DOCSIS, you can not
> always send, but you have to wait till you get your time slice over PLOAM.

Hello!

I think same applies also for 1000BASE-PX or 10GBASE-PR GEPON passive
ethernet networks (Beware GPON != GEPON).

But I think this is not an issue. There are also other "shared medium"
technologies (e.g. mobile network; or WiFi on DFS channels) for which
exists hardware supported by mainline kernel (3G/LTE modems).

> In addition the GPON SFP stick also have to talk the OMCI protocol which
> allows to operator to configure all sorts of layer 2 things. They can also
> login to your SFP stick. ;-)

Yes, I just described it as "application" layer. It is complicated and
basically something which is not suppose to be implemented in kernel.
Plus GPON vendors extends (standardized) OMCI protocol with their own
extension which means that without their implementation on client side
it is impossible to fully establish connection to "server" OLT part.

> There are also some passive GPON SFP sticks which just translate between
> electrical and optical signals, but to operate them you need a GPON MAC and
> managed layer on your host.

Interesting... Do you know where to buy or test such passive GPON SFP sticks?

And is there some documentation how these sticks works? And what kind of
phy mode they are using over SerDes? Because due to different inbound
and outbound speeds it cannot be neither 1000base-x nor 2500base-x.

> Adding GPON support properly into Linux is not an easy task, Linux would
> probably need a subsystem with a complexity compared to cfg80211 + hostapd.

Yea... But maybe it could be easier to implement just "client part"
(ONU/ONT) without "server part" (OLT).

> Is there a list of things these GPON sticks running Linux should do better
> in the future? For example what to avoid in the EEPROM emulation handling?

Well... If you think that it is possible to address these issues
directly to GPON vendors and they will fix them in next version of GPON
SFP sticks, I could try to find some time and prepare list of lot of
issues...

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: What is inside GPON SFP module?
  2021-06-05 13:31                         ` What is inside GPON SFP module? Pali Rohár
@ 2021-06-05 14:17                           ` Hauke Mehrtens
  0 siblings, 0 replies; 29+ messages in thread
From: Hauke Mehrtens @ 2021-06-05 14:17 UTC (permalink / raw)
  To: Pali Rohár
  Cc: Vladimir Oltean, Russell King (Oracle),
	Madalin Bucur, Andrew Lunn, Igal Liberman, Shruti Kanetkar,
	Emil Medve, Scott Wood, Rob Herring, Michael Ellerman,
	Benjamin Herrenschmidt, netdev, devicetree, linux-kernel,
	Camelia Alexandra Groza (OSS)


[-- Attachment #1.1.1: Type: text/plain, Size: 6570 bytes --]

On 6/5/21 3:31 PM, Pali Rohár wrote:
> On Saturday 05 June 2021 15:04:55 Hauke Mehrtens wrote:
>> On 6/5/21 2:50 PM, Pali Rohár wrote:
>>> On Saturday 05 June 2021 15:26:39 Vladimir Oltean wrote:
>>>> On Sat, Jun 05, 2021 at 01:33:07AM +0100, Russell King (Oracle) wrote:
>>>>> 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.
>>>>
>>>> Pardon my ignorance, but what is inside a GPON ONT module? Just a laser
>>>> and some amplifiers? So it would still be the MAC PCS negotiating flow
>>>> control with the remote link partner? That's a different use case
>>>> from
>> a
>>>> PHY transmitting the negotiated link modes to the MAC.
>>>
>>> Hello Vladimir! All GPON ONU/ONT SFP modules which I have tested, are
>>> fully featured mini computers. It is some SoC with powerful CPU, fiber
>>> part, at least two NICs and then two phys, one for fiber part and one
>>> for "SFP"-part (in most cases 1000base-x or 2500base-x). On SoC inside
>>> is running fully featured operating system, in most cases Linux kernel
>>> 2.6.3x and tons of userspace applications which implements "application"
>>> layer of GPON protocol -- the most important part. If OEM vendor of GPON
>>> SFP stick did not locked it, you can connect to this "computer" via
>>> telnet or web browser and configure some settings, including GPON stuff
>>> and also how GPON network is connected to SFP part -- e.g. it can be
>>> fully featured IPv4 router with NAT or just plain bridge mode where
>>> "ethernet data packets" (those which are not part of ISP configuration
>>> protocol) are pass-throw to SFP phy 1000base-x to host CPU. GPON is not
>>> ethernet, it is some incompatible and heavily layered extension on ATM.
>>> Originally I thought that ATM is long ago dead (as I saw it in used last
>>> time in ADSL2) but it is still alive and cause issues... I think it does
>>> not use 8b/10b encoding and therefore cannot be directly mapped to
>>> 1000base-x. Also GPON uses different wavelengths for inbound and
>>> outbound traffic. And to make it even more complicated it uses totally
>>> nonstandard asynchronous speeds, inbound is 2488.32Mbit/s, outbound is
>>> 1244.16Mbit/s. So I guess CPU/SoC with GPON support (something which is
>>> inside that GPON ONU/ONT stick) must use totally different modes for
>>> which we do not have any option in DTS yet.
>>>
>>> So once mainline kernel will support these "computers" with GPON support
>>> it would be required to define new kind of phy modes... But I do not
>>> think it happens and all OEM vendors are using 2.6.3x kernels their
>>> userspace GPON implementation is closed has tons of secrets.
>>>
>>
>> Hi,
>>
>> This description of the GPON SFP sticks is correct, but it misses some 
of
>> the complexity. ;-) GPON is also a shared medium like DOCSIS, you can not
>> always send, but you have to wait till you get your time slice over PLOAM.
> 
> Hello!
> 
> I think same applies also for 1000BASE-PX or 10GBASE-PR GEPON passive
> ethernet networks (Beware GPON != GEPON).

There is one family standardized by the ITU (GPON, XGPON, XGSPON, 
NGPON2) and an other family standardized by the IEEE (EPON, GEPON). They 
solve more or less the same problem, just in a different way.

> But I think this is not an issue. There are also other "shared medium"
> technologies (e.g. mobile network; or WiFi on DFS channels) for which
> exists hardware supported by mainline kernel (3G/LTE modems).

Yes, then you just need a MAC which can handle it. It is more complex 
than a normal Ethernet MAC.

>> In addition the GPON SFP stick also have to talk the OMCI protocol which
>> allows to operator to configure all sorts of layer 2 things. They can also
>> login to your SFP stick. ;-)
> 
> Yes, I just described it as "application" layer. It is complicated and
> basically something which is not suppose to be implemented in kernel.
> Plus GPON vendors extends (standardized) OMCI protocol with their own
> extension which means that without their implementation on client side
> it is impossible to fully establish connection to "server" OLT part.

You can use one software stack without (many) vendor OLT specific 
workarounds which works with multiple of the big OLT vendors. The OMCI 
protocol definition is also publicly available and there are no vendor 
extensions needed for normal operations nowadays. The specification 
leaves room for interpretation in some parts and some OMCI ONU stacks 
are "optimized" for a specific OLT vendor.

>> There are also some passive GPON SFP sticks which just translate between
>> electrical and optical signals, but to operate them you need a GPON MAC and
>> managed layer on your host.
> 
> Interesting... Do you know where to buy or test such passive GPON SFP sticks?

Most of the 10€ GPON OLT sticks are such passive sticks, but the 
wavelengths are in the wrong order.

I do not know where exactly to buy them, but there are multiple vendors 
building such sticks. To operate them on a GPON fiber you still need the 
GPON MAC.

> And is there some documentation how these sticks works? And what kind of
> phy mode they are using over SerDes? Because due to different inbound
> and outbound speeds it cannot be neither 1000base-x nor 2500base-x.

I do not know.

>> Adding GPON support properly into Linux is not an easy task, Linux would
>> probably need a subsystem with a complexity compared to cfg80211 + hostapd.
> 
> Yea... But maybe it could be easier to implement just "client part"
> (ONU/ONT) without "server part" (OLT).

Yes, the ONU and OLT part are pretty different on the Management layer 
anyway.

>> Is there a list of things these GPON sticks running Linux should do better
>> in the future? For example what to avoid in the EEPROM emulation handling?
> 
> Well... If you think that it is possible to address these issues
> directly to GPON vendors and they will fix them in next version of GPON
> SFP sticks, I could try to find some time and prepare list of lot of
> issues...

I can not promise that, but I can try.
There are some constrains like the EEPROM is only available after the 
Linux booted up, so it takes some time after it got power.

Hauke

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 10027 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: What is inside GPON SFP module? (Was: Re: Unsupported phy-connection-type sgmii-2500 in arch/powerpc/boot/dts/fsl/t1023rdb.dts)
  2021-06-05 13:04                       ` Hauke Mehrtens
  2021-06-05 13:31                         ` What is inside GPON SFP module? Pali Rohár
@ 2021-06-05 14:41                         ` Russell King (Oracle)
  2021-06-08 10:33                           ` What is inside GPON SFP module? Pali Rohár
  1 sibling, 1 reply; 29+ messages in thread
From: Russell King (Oracle) @ 2021-06-05 14:41 UTC (permalink / raw)
  To: Hauke Mehrtens
  Cc: Pali Rohár, Vladimir Oltean, Madalin Bucur, Andrew Lunn,
	Igal Liberman, Shruti Kanetkar, Emil Medve, Scott Wood,
	Rob Herring, Michael Ellerman, Benjamin Herrenschmidt, netdev,
	devicetree, linux-kernel, Camelia Alexandra Groza (OSS)

On Sat, Jun 05, 2021 at 03:04:55PM +0200, Hauke Mehrtens wrote:
> Is there a list of things these GPON sticks running Linux should do better
> in the future? For example what to avoid in the EEPROM emulation handling?

That is just not worth persuing. Large ISP-companies who have plenty of
buying power have tried to get issues with GPON sticks resolved, and the
response from the GPON stick manufacturers has not been helpful. I had
contracted with a national telco over this problem in recent years, and
I know they tried their best.

If large ISP companies who are significant customers can't effect any
fixes, you can be absolutely sure that the voluntary effort around the
Linux kernel will have no effect.

Yes, we list the modules that don't work well in the kernel source, and
sometimes we name and shame them, but they don't care.

For example, there is are a few modules that take up to 60 seconds
before they respond to any I2C requests, because the I2C is entirely
emulated by the Linux kernel running on the stick, and it takes that
long for the stick to boot. Will that ever get fixed? Probably not
without a hardware redesign. Will that happen? I really doubt it, and
eevn if it did it doesn't affect the millions of sticks already out
there.

IMHO trying to get these issues fixed is pie in the sky.


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

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: What is inside GPON SFP module?
  2021-06-05 14:41                         ` What is inside GPON SFP module? (Was: Re: Unsupported phy-connection-type sgmii-2500 in arch/powerpc/boot/dts/fsl/t1023rdb.dts) Russell King (Oracle)
@ 2021-06-08 10:33                           ` Pali Rohár
  0 siblings, 0 replies; 29+ messages in thread
From: Pali Rohár @ 2021-06-08 10:33 UTC (permalink / raw)
  To: Russell King (Oracle)
  Cc: Hauke Mehrtens, Vladimir Oltean, Madalin Bucur, Andrew Lunn,
	Igal Liberman, Shruti Kanetkar, Emil Medve, Scott Wood,
	Rob Herring, Michael Ellerman, Benjamin Herrenschmidt, netdev,
	devicetree, linux-kernel, Camelia Alexandra Groza (OSS)

On Saturday 05 June 2021 15:41:05 Russell King (Oracle) wrote:
> On Sat, Jun 05, 2021 at 03:04:55PM +0200, Hauke Mehrtens wrote:
> > Is there a list of things these GPON sticks running Linux should do better
> > in the future? For example what to avoid in the EEPROM emulation handling?
> 
> That is just not worth persuing. Large ISP-companies who have plenty of
> buying power have tried to get issues with GPON sticks resolved, and the
> response from the GPON stick manufacturers has not been helpful. I had
> contracted with a national telco over this problem in recent years, and
> I know they tried their best.
> 
> If large ISP companies who are significant customers can't effect any
> fixes, you can be absolutely sure that the voluntary effort around the
> Linux kernel will have no effect.

I see :-( So it does not make sense to try to do anything...

> Yes, we list the modules that don't work well in the kernel source, and
> sometimes we name and shame them, but they don't care.
> 
> For example, there is are a few modules that take up to 60 seconds
> before they respond to any I2C requests, because the I2C is entirely
> emulated by the Linux kernel running on the stick, and it takes that
> long for the stick to boot. Will that ever get fixed? Probably not
> without a hardware redesign. Will that happen? I really doubt it, and
> eevn if it did it doesn't affect the millions of sticks already out
> there.
> 
> IMHO trying to get these issues fixed is pie in the sky.
> 
> 
> -- 
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Unsupported phy-connection-type sgmii-2500 in arch/powerpc/boot/dts/fsl/t1023rdb.dts
  2021-06-04 23:34               ` Pali Rohár
  2021-06-05  0:33                 ` Russell King (Oracle)
@ 2021-06-19 20:35                 ` Pali Rohár
  2021-07-04 13:43                 ` [PATCH] powerpc/fsl/dts: Fix phy-connection-type for fm1mac3 Pali Rohár
  2 siblings, 0 replies; 29+ messages in thread
From: Pali Rohár @ 2021-06-19 20:35 UTC (permalink / raw)
  To: Madalin Bucur
  Cc: Andrew Lunn, Russell King, Igal Liberman, Shruti Kanetkar,
	Emil Medve, Scott Wood, Rob Herring, Michael Ellerman,
	Benjamin Herrenschmidt, netdev, devicetree, linux-kernel,
	Camelia Alexandra Groza (OSS)

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@lunn.ch>
> > > Sent: 04 June 2021 23:24
> > > To: Madalin Bucur <madalin.bucur@nxp.com>
> > > Cc: Russell King <linux@armlinux.org.uk>; Pali Rohár <pali@kernel.org>;
> > > 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
> > > 
> > > > 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?

^ permalink raw reply	[flat|nested] 29+ messages in thread

* [PATCH] powerpc/fsl/dts: Fix phy-connection-type for fm1mac3
  2021-06-04 23:34               ` Pali Rohár
  2021-06-05  0:33                 ` Russell King (Oracle)
  2021-06-19 20:35                 ` Unsupported phy-connection-type sgmii-2500 in arch/powerpc/boot/dts/fsl/t1023rdb.dts Pali Rohár
@ 2021-07-04 13:43                 ` Pali Rohár
  2021-07-14 17:11                   ` Scott Wood
  2 siblings, 1 reply; 29+ messages in thread
From: Pali Rohár @ 2021-07-04 13:43 UTC (permalink / raw)
  To: Andrew Lunn, Russell King, Madalin Bucur, Camelia Alexandra Groza (OSS)
  Cc: Scott Wood, Rob Herring, Michael Ellerman,
	Benjamin Herrenschmidt, Marek Behún, netdev, devicetree,
	linux-kernel

Property phy-connection-type contains invalid value "sgmii-2500" per scheme
defined in file ethernet-controller.yaml.

Correct phy-connection-type value should be "2500base-x".

Signed-off-by: Pali Rohár <pali@kernel.org>
Fixes: 84e0f1c13806 ("powerpc/mpc85xx: Add MDIO bus muxing support to the board device tree(s)")
---
 arch/powerpc/boot/dts/fsl/t1023rdb.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/boot/dts/fsl/t1023rdb.dts b/arch/powerpc/boot/dts/fsl/t1023rdb.dts
index 5ba6fbfca274..f82f85c65964 100644
--- a/arch/powerpc/boot/dts/fsl/t1023rdb.dts
+++ b/arch/powerpc/boot/dts/fsl/t1023rdb.dts
@@ -154,7 +154,7 @@
 
 			fm1mac3: ethernet@e4000 {
 				phy-handle = <&sgmii_aqr_phy3>;
-				phy-connection-type = "sgmii-2500";
+				phy-connection-type = "2500base-x";
 				sleep = <&rcpm 0x20000000>;
 			};
 
-- 
2.20.1


^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [PATCH] powerpc/fsl/dts: Fix phy-connection-type for fm1mac3
  2021-07-04 13:43                 ` [PATCH] powerpc/fsl/dts: Fix phy-connection-type for fm1mac3 Pali Rohár
@ 2021-07-14 17:11                   ` Scott Wood
  2021-08-27 11:38                     ` Pali Rohár
  0 siblings, 1 reply; 29+ messages in thread
From: Scott Wood @ 2021-07-14 17:11 UTC (permalink / raw)
  To: Pali Rohár, Andrew Lunn, Russell King, Madalin Bucur,
	Camelia Alexandra Groza (OSS)
  Cc: Rob Herring, Michael Ellerman, Benjamin Herrenschmidt,
	Marek Behún, netdev, devicetree, linux-kernel

On Sun, 2021-07-04 at 15:43 +0200, Pali Rohár wrote:
> Property phy-connection-type contains invalid value "sgmii-2500" per scheme
> defined in file ethernet-controller.yaml.
> 
> Correct phy-connection-type value should be "2500base-x".
> 
> Signed-off-by: Pali Rohár <pali@kernel.org>
> Fixes: 84e0f1c13806 ("powerpc/mpc85xx: Add MDIO bus muxing support to the
> board device tree(s)")
> ---
>  arch/powerpc/boot/dts/fsl/t1023rdb.dts | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/powerpc/boot/dts/fsl/t1023rdb.dts
> b/arch/powerpc/boot/dts/fsl/t1023rdb.dts
> index 5ba6fbfca274..f82f85c65964 100644
> --- a/arch/powerpc/boot/dts/fsl/t1023rdb.dts
> +++ b/arch/powerpc/boot/dts/fsl/t1023rdb.dts
> @@ -154,7 +154,7 @@
>  
>                         fm1mac3: ethernet@e4000 {
>                                 phy-handle = <&sgmii_aqr_phy3>;
> -                               phy-connection-type = "sgmii-2500";
> +                               phy-connection-type = "2500base-x";
>                                 sleep = <&rcpm 0x20000000>;
>                         };
>  

Acked-by: Scott Wood <oss@buserror.net>

-Scott



^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [PATCH] powerpc/fsl/dts: Fix phy-connection-type for fm1mac3
  2021-07-14 17:11                   ` Scott Wood
@ 2021-08-27 11:38                     ` Pali Rohár
  2021-09-28 21:39                       ` Pali Rohár
  0 siblings, 1 reply; 29+ messages in thread
From: Pali Rohár @ 2021-08-27 11:38 UTC (permalink / raw)
  To: Scott Wood
  Cc: Andrew Lunn, Russell King, Madalin Bucur,
	Camelia Alexandra Groza (OSS),
	Rob Herring, Michael Ellerman, Benjamin Herrenschmidt,
	Marek Behún, netdev, devicetree, linux-kernel

On Wednesday 14 July 2021 12:11:49 Scott Wood wrote:
> On Sun, 2021-07-04 at 15:43 +0200, Pali Rohár wrote:
> > Property phy-connection-type contains invalid value "sgmii-2500" per scheme
> > defined in file ethernet-controller.yaml.
> > 
> > Correct phy-connection-type value should be "2500base-x".
> > 
> > Signed-off-by: Pali Rohár <pali@kernel.org>
> > Fixes: 84e0f1c13806 ("powerpc/mpc85xx: Add MDIO bus muxing support to the
> > board device tree(s)")
> > ---
> >  arch/powerpc/boot/dts/fsl/t1023rdb.dts | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/arch/powerpc/boot/dts/fsl/t1023rdb.dts
> > b/arch/powerpc/boot/dts/fsl/t1023rdb.dts
> > index 5ba6fbfca274..f82f85c65964 100644
> > --- a/arch/powerpc/boot/dts/fsl/t1023rdb.dts
> > +++ b/arch/powerpc/boot/dts/fsl/t1023rdb.dts
> > @@ -154,7 +154,7 @@
> >  
> >                         fm1mac3: ethernet@e4000 {
> >                                 phy-handle = <&sgmii_aqr_phy3>;
> > -                               phy-connection-type = "sgmii-2500";
> > +                               phy-connection-type = "2500base-x";
> >                                 sleep = <&rcpm 0x20000000>;
> >                         };
> >  
> 
> Acked-by: Scott Wood <oss@buserror.net>
> 
> -Scott

Hello! If there is not any objection, could you take this patch?

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [PATCH] powerpc/fsl/dts: Fix phy-connection-type for fm1mac3
  2021-08-27 11:38                     ` Pali Rohár
@ 2021-09-28 21:39                       ` Pali Rohár
  2021-09-29 14:25                         ` Andrew Lunn
  0 siblings, 1 reply; 29+ messages in thread
From: Pali Rohár @ 2021-09-28 21:39 UTC (permalink / raw)
  To: Andrew Lunn, Russell King, Madalin Bucur,
	Camelia Alexandra Groza (OSS),
	Rob Herring, Michael Ellerman, Benjamin Herrenschmidt,
	Marek Behún, Scott Wood
  Cc: netdev, devicetree, linux-kernel

On Friday 27 August 2021 13:38:36 Pali Rohár wrote:
> On Wednesday 14 July 2021 12:11:49 Scott Wood wrote:
> > On Sun, 2021-07-04 at 15:43 +0200, Pali Rohár wrote:
> > > Property phy-connection-type contains invalid value "sgmii-2500" per scheme
> > > defined in file ethernet-controller.yaml.
> > > 
> > > Correct phy-connection-type value should be "2500base-x".
> > > 
> > > Signed-off-by: Pali Rohár <pali@kernel.org>
> > > Fixes: 84e0f1c13806 ("powerpc/mpc85xx: Add MDIO bus muxing support to the
> > > board device tree(s)")
> > > ---
> > >  arch/powerpc/boot/dts/fsl/t1023rdb.dts | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/arch/powerpc/boot/dts/fsl/t1023rdb.dts
> > > b/arch/powerpc/boot/dts/fsl/t1023rdb.dts
> > > index 5ba6fbfca274..f82f85c65964 100644
> > > --- a/arch/powerpc/boot/dts/fsl/t1023rdb.dts
> > > +++ b/arch/powerpc/boot/dts/fsl/t1023rdb.dts
> > > @@ -154,7 +154,7 @@
> > >  
> > >                         fm1mac3: ethernet@e4000 {
> > >                                 phy-handle = <&sgmii_aqr_phy3>;
> > > -                               phy-connection-type = "sgmii-2500";
> > > +                               phy-connection-type = "2500base-x";
> > >                                 sleep = <&rcpm 0x20000000>;
> > >                         };
> > >  
> > 
> > Acked-by: Scott Wood <oss@buserror.net>
> > 
> > -Scott
> 
> Hello! If there is not any objection, could you take this patch?

Hello! I would like to remind this patch.

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [PATCH] powerpc/fsl/dts: Fix phy-connection-type for fm1mac3
  2021-09-28 21:39                       ` Pali Rohár
@ 2021-09-29 14:25                         ` Andrew Lunn
  2021-10-02  9:06                           ` Pali Rohár
  0 siblings, 1 reply; 29+ messages in thread
From: Andrew Lunn @ 2021-09-29 14:25 UTC (permalink / raw)
  To: Pali Rohár
  Cc: Russell King, Madalin Bucur, Camelia Alexandra Groza (OSS),
	Rob Herring, Michael Ellerman, Benjamin Herrenschmidt,
	Marek Behún, Scott Wood, netdev, devicetree, linux-kernel

On Tue, Sep 28, 2021 at 11:39:18PM +0200, Pali Rohár wrote:
> On Friday 27 August 2021 13:38:36 Pali Rohár wrote:
> > On Wednesday 14 July 2021 12:11:49 Scott Wood wrote:
> > > On Sun, 2021-07-04 at 15:43 +0200, Pali Rohár wrote:
> > > > Property phy-connection-type contains invalid value "sgmii-2500" per scheme
> > > > defined in file ethernet-controller.yaml.
> > > > 
> > > > Correct phy-connection-type value should be "2500base-x".
> > > > 
> > > > Signed-off-by: Pali Rohár <pali@kernel.org>
> > > > Fixes: 84e0f1c13806 ("powerpc/mpc85xx: Add MDIO bus muxing support to the
> > > > board device tree(s)")
> > > > ---
> > > >  arch/powerpc/boot/dts/fsl/t1023rdb.dts | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > 
> > > > diff --git a/arch/powerpc/boot/dts/fsl/t1023rdb.dts
> > > > b/arch/powerpc/boot/dts/fsl/t1023rdb.dts
> > > > index 5ba6fbfca274..f82f85c65964 100644
> > > > --- a/arch/powerpc/boot/dts/fsl/t1023rdb.dts
> > > > +++ b/arch/powerpc/boot/dts/fsl/t1023rdb.dts
> > > > @@ -154,7 +154,7 @@
> > > >  
> > > >                         fm1mac3: ethernet@e4000 {
> > > >                                 phy-handle = <&sgmii_aqr_phy3>;
> > > > -                               phy-connection-type = "sgmii-2500";
> > > > +                               phy-connection-type = "2500base-x";
> > > >                                 sleep = <&rcpm 0x20000000>;
> > > >                         };
> > > >  
> > > 
> > > Acked-by: Scott Wood <oss@buserror.net>
> > > 
> > > -Scott
> > 
> > Hello! If there is not any objection, could you take this patch?
> 
> Hello! I would like to remind this patch.

Hi Pali

I suggest you resend, and with To: Michael Ellerman <mpe@ellerman.id.au>
to make it clear who you expect to pick up the
patch. Michael seems to do the Maintainer work in
arch/powerpc/boot/dts/

	Andrew

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [PATCH] powerpc/fsl/dts: Fix phy-connection-type for fm1mac3
  2021-09-29 14:25                         ` Andrew Lunn
@ 2021-10-02  9:06                           ` Pali Rohár
  0 siblings, 0 replies; 29+ messages in thread
From: Pali Rohár @ 2021-10-02  9:06 UTC (permalink / raw)
  To: Andrew Lunn
  Cc: Russell King, Madalin Bucur, Camelia Alexandra Groza (OSS),
	Rob Herring, Michael Ellerman, Benjamin Herrenschmidt,
	Marek Behún, Scott Wood, netdev, devicetree, linux-kernel

On Wednesday 29 September 2021 16:25:01 Andrew Lunn wrote:
> On Tue, Sep 28, 2021 at 11:39:18PM +0200, Pali Rohár wrote:
> > On Friday 27 August 2021 13:38:36 Pali Rohár wrote:
> > > On Wednesday 14 July 2021 12:11:49 Scott Wood wrote:
> > > > On Sun, 2021-07-04 at 15:43 +0200, Pali Rohár wrote:
> > > > > Property phy-connection-type contains invalid value "sgmii-2500" per scheme
> > > > > defined in file ethernet-controller.yaml.
> > > > > 
> > > > > Correct phy-connection-type value should be "2500base-x".
> > > > > 
> > > > > Signed-off-by: Pali Rohár <pali@kernel.org>
> > > > > Fixes: 84e0f1c13806 ("powerpc/mpc85xx: Add MDIO bus muxing support to the
> > > > > board device tree(s)")
> > > > > ---
> > > > >  arch/powerpc/boot/dts/fsl/t1023rdb.dts | 2 +-
> > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/arch/powerpc/boot/dts/fsl/t1023rdb.dts
> > > > > b/arch/powerpc/boot/dts/fsl/t1023rdb.dts
> > > > > index 5ba6fbfca274..f82f85c65964 100644
> > > > > --- a/arch/powerpc/boot/dts/fsl/t1023rdb.dts
> > > > > +++ b/arch/powerpc/boot/dts/fsl/t1023rdb.dts
> > > > > @@ -154,7 +154,7 @@
> > > > >  
> > > > >                         fm1mac3: ethernet@e4000 {
> > > > >                                 phy-handle = <&sgmii_aqr_phy3>;
> > > > > -                               phy-connection-type = "sgmii-2500";
> > > > > +                               phy-connection-type = "2500base-x";
> > > > >                                 sleep = <&rcpm 0x20000000>;
> > > > >                         };
> > > > >  
> > > > 
> > > > Acked-by: Scott Wood <oss@buserror.net>
> > > > 
> > > > -Scott
> > > 
> > > Hello! If there is not any objection, could you take this patch?
> > 
> > Hello! I would like to remind this patch.
> 
> Hi Pali
> 
> I suggest you resend, and with To: Michael Ellerman <mpe@ellerman.id.au>
> to make it clear who you expect to pick up the
> patch. Michael seems to do the Maintainer work in
> arch/powerpc/boot/dts/
> 
> 	Andrew

Done: https://lore.kernel.org/lkml/20211002090409.3833-1-pali@kernel.org/T/#u

^ permalink raw reply	[flat|nested] 29+ messages in thread

end of thread, other threads:[~2021-10-02  9:06 UTC | newest]

Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-06-03 14:34 Unsupported phy-connection-type sgmii-2500 in arch/powerpc/boot/dts/fsl/t1023rdb.dts Pali Rohár
2021-06-03 15:12 ` Andrew Lunn
2021-06-03 19:48   ` Pali Rohár
2021-06-04  7:35     ` Madalin Bucur
2021-06-04 17:32       ` Pali Rohár
2021-06-04 19:13         ` Madalin Bucur
2021-06-04 19:27       ` Russell King (Oracle)
2021-06-04 19:39         ` Madalin Bucur
2021-06-04 20:00           ` Russell King (Oracle)
2021-06-04 21:37             ` Madalin Bucur
2021-06-04 20:23           ` Andrew Lunn
2021-06-04 21:47             ` Madalin Bucur
2021-06-04 23:34               ` Pali Rohár
2021-06-05  0:33                 ` Russell King (Oracle)
2021-06-05 12:26                   ` Vladimir Oltean
2021-06-05 12:50                     ` What is inside GPON SFP module? (Was: Re: Unsupported phy-connection-type sgmii-2500 in arch/powerpc/boot/dts/fsl/t1023rdb.dts) Pali Rohár
2021-06-05 13:04                       ` Hauke Mehrtens
2021-06-05 13:31                         ` What is inside GPON SFP module? Pali Rohár
2021-06-05 14:17                           ` Hauke Mehrtens
2021-06-05 14:41                         ` What is inside GPON SFP module? (Was: Re: Unsupported phy-connection-type sgmii-2500 in arch/powerpc/boot/dts/fsl/t1023rdb.dts) Russell King (Oracle)
2021-06-08 10:33                           ` What is inside GPON SFP module? Pali Rohár
2021-06-19 20:35                 ` Unsupported phy-connection-type sgmii-2500 in arch/powerpc/boot/dts/fsl/t1023rdb.dts Pali Rohár
2021-07-04 13:43                 ` [PATCH] powerpc/fsl/dts: Fix phy-connection-type for fm1mac3 Pali Rohár
2021-07-14 17:11                   ` Scott Wood
2021-08-27 11:38                     ` Pali Rohár
2021-09-28 21:39                       ` Pali Rohár
2021-09-29 14:25                         ` Andrew Lunn
2021-10-02  9:06                           ` Pali Rohár
2021-06-04 23:18         ` Unsupported phy-connection-type sgmii-2500 in arch/powerpc/boot/dts/fsl/t1023rdb.dts Pali Rohár

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.