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

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.

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

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:

quoted

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:

[off-list ref]: 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

-----Original Message-----
From: Pali Rohár <pali@kernel.org>
Sent: 03 June 2021 22:49
To: Andrew Lunn <andrew@lunn.ch>
Cc: Igal Liberman <redacted>; Shruti Kanetkar
[off-list ref]; Emil Medve [off-list ref]; Scott
Wood [off-list ref]; Rob Herring [off-list ref]; Michael
Ellerman [off-list ref]; Benjamin Herrenschmidt
[off-list ref]; Madalin Bucur [off-list ref]; Russell
King [off-list ref]; 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:

quoted

On Thu, Jun 03, 2021 at 04:34:53PM +0200, Pali Rohár wrote:

quoted

Hello!

In commit 84e0f1c13806 ("powerpc/mpc85xx: Add MDIO bus muxing support

to

quoted

quoted

the board device tree(s)") was added following DT property into DT

node:

quoted

quoted

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

quoted

quoted

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:

[off-list ref]: 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

quoted

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.

quoted

	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

Hello!

On Friday 04 June 2021 07:35:33 Madalin Bucur wrote:

quoted

-----Original Message-----
From: Pali Rohár <pali@kernel.org>
Sent: 03 June 2021 22:49
To: Andrew Lunn <andrew@lunn.ch>
Cc: Igal Liberman <redacted>; Shruti Kanetkar
[off-list ref]; Emil Medve [off-list ref]; Scott
Wood [off-list ref]; Rob Herring [off-list ref]; Michael
Ellerman [off-list ref]; Benjamin Herrenschmidt
[off-list ref]; Madalin Bucur [off-list ref]; Russell
King [off-list ref]; 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:

quoted

On Thu, Jun 03, 2021 at 04:34:53PM +0200, Pali Rohár wrote:

quoted

Hello!

In commit 84e0f1c13806 ("powerpc/mpc85xx: Add MDIO bus muxing support

to

quoted

quoted

the board device tree(s)") was added following DT property into DT

node:

quoted

quoted

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

quoted

quoted

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:

[off-list ref]: 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

quoted

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.

quoted

	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

-----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
[off-list ref]; Shruti Kanetkar [off-list ref];
Emil Medve [off-list ref]; Scott Wood [off-list ref];
Rob Herring [off-list ref]; Michael Ellerman [off-list ref];
Benjamin Herrenschmidt [off-list ref]; Russell King
[off-list ref]; netdev@vger.kernel.org;
devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; Camelia
Alexandra Groza (OSS) [off-list ref]
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:

quoted

quoted

-----Original Message-----
From: Pali Rohár <pali@kernel.org>
Sent: 03 June 2021 22:49
To: Andrew Lunn <andrew@lunn.ch>
Cc: Igal Liberman <redacted>; Shruti Kanetkar
[off-list ref]; Emil Medve [off-list ref];

Scott

quoted

quoted

Wood [off-list ref]; Rob Herring [off-list ref]; Michael
Ellerman [off-list ref]; Benjamin Herrenschmidt
[off-list ref]; Madalin Bucur [off-list ref];

Russell

quoted

quoted

King [off-list ref]; 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:

quoted

On Thu, Jun 03, 2021 at 04:34:53PM +0200, Pali Rohár wrote:

quoted

Hello!

In commit 84e0f1c13806 ("powerpc/mpc85xx: Add MDIO bus muxing

support

quoted

quoted

to

quoted

quoted

the board device tree(s)") was added following DT property into DT

node:

quoted

quoted

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

quoted

quoted

file include/linux/phy.h. In my opinion it should be "2500base-x"

as

quoted

quoted

quoted

quoted

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

quoted

quoted

quoted

quoted

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:

[off-list ref]: connect to

freescale.com[192.88.156.33]:25:

quoted

quoted

Connection timed out

Do you have other way how to contact maintainers of that DTS file?
arch/powerpc/boot/dts/fsl/t1023rdb.dts

quoted

PHY mode sgmii-2500 does not exist in mainline.

Yes, this is reason why I sent this email. In DTS is specified this

mode

quoted

quoted

which does not exist.

quoted

	Andrew

Hi, the Freescale emails no longer work, years after Freescale joined

NXP.

quoted

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

quoted

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.

quoted

The statement that it does not exist is not accurate, it exists in HW,

and

quoted

it is described as such in the device tree. Whether or not it is

properly

quoted

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.

quoted

2500Base-X started to be added to device trees four years later, it

should

quoted

be compatible/interworking but it is less specific on the actual

implementation

quoted

details (denotes 2.5G speed, 8b/10b coding, which is true for this

overclocked

quoted

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.

quoted

There were some discussions a while ago about the mix or even confusion

between

quoted

the actual HW description (that's what the dts is supposed to do) and

the settings

quoted

one wants to represent in SW (i.e. speed) denoted loosely by

denominations like

quoted

10G Base-R.

Regards,
Madalin

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!

-----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 [off-list ref]; Shruti Kanetkar
[off-list ref]; Emil Medve [off-list ref]; Scott
Wood [off-list ref]; Rob Herring [off-list ref]; Michael
Ellerman [off-list ref]; Benjamin Herrenschmidt
[off-list ref]; netdev@vger.kernel.org;
devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; Camelia
Alexandra Groza (OSS) [off-list ref]
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:

quoted

Hi, the Freescale emails no longer work, years after Freescale joined

NXP.

quoted

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

quoted

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

quoted

it is described as such in the device tree. Whether or not it is

properly

quoted

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?

quoted

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

quoted

be compatible/interworking but it is less specific on the actual

implementation

quoted

details (denotes 2.5G speed, 8b/10b coding, which is true for this

overclocked

quoted

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.

quoted

There were some discussions a while ago about the mix or even confusion

between

quoted

the actual HW description (that's what the dts is supposed to do) and

the settings

quoted

one wants to represent in SW (i.e. speed) denoted loosely by

denominations like

quoted

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

On Fri, Jun 04, 2021 at 07:39:10PM +0000, Madalin Bucur wrote:

quoted

-----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 [off-list ref]; Shruti Kanetkar
[off-list ref]; Emil Medve [off-list ref]; Scott
Wood [off-list ref]; Rob Herring [off-list ref]; Michael
Ellerman [off-list ref]; Benjamin Herrenschmidt
[off-list ref]; netdev@vger.kernel.org;
devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; Camelia
Alexandra Groza (OSS) [off-list ref]
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:

quoted

Hi, the Freescale emails no longer work, years after Freescale joined

NXP.

quoted

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

quoted

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

quoted

it is described as such in the device tree. Whether or not it is

properly

quoted

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?

quoted

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

quoted

be compatible/interworking but it is less specific on the actual

implementation

quoted

details (denotes 2.5G speed, 8b/10b coding, which is true for this

overclocked

quoted

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.

quoted

There were some discussions a while ago about the mix or even confusion

between

quoted

the actual HW description (that's what the dts is supposed to do) and

the settings

quoted

one wants to represent in SW (i.e. speed) denoted loosely by

denominations like

quoted

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!

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

-----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 [off-list ref]; Shruti Kanetkar
[off-list ref]; Emil Medve [off-list ref]; Scott
Wood [off-list ref]; Rob Herring [off-list ref]; Michael
Ellerman [off-list ref]; Benjamin Herrenschmidt
[off-list ref]; netdev@vger.kernel.org;
devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; Camelia
Alexandra Groza (OSS) [off-list ref]
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:

quoted

quoted

-----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 [off-list ref]; Shruti Kanetkar
[off-list ref]; Emil Medve [off-list ref];

Scott

quoted

quoted

Wood [off-list ref]; Rob Herring [off-list ref]; Michael
Ellerman [off-list ref]; Benjamin Herrenschmidt
[off-list ref]; netdev@vger.kernel.org;
devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; Camelia
Alexandra Groza (OSS) [off-list ref]
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:

quoted

Hi, the Freescale emails no longer work, years after Freescale

joined

quoted

quoted

NXP.

quoted

Also, the first four recipients no longer work for NXP.

In regards to the sgmii-2500 you see in the device tree, it

describes

quoted

quoted

SGMII

quoted

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

quoted

quoted

quoted

	using XAUI electricals. For the PCS and MAC layers, it looks

exactly

quoted

quoted

quoted

	like 1G SGMII, just with a faster clock.

The statement that it does not exist is not accurate, it exists in

HW,

quoted

quoted

and

quoted

it is described as such in the device tree. Whether or not it is

properly

quoted

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?

quoted

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

quoted

be compatible/interworking but it is less specific on the actual

implementation

quoted

details (denotes 2.5G speed, 8b/10b coding, which is true for this

overclocked

quoted

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.

quoted

There were some discussions a while ago about the mix or even

confusion

quoted

quoted

between

quoted

the actual HW description (that's what the dts is supposed to do)

and

quoted

quoted

the settings

quoted

one wants to represent in SW (i.e. speed) denoted loosely by

denominations like

quoted

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

quoted

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

-----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 [off-list ref]; Shruti Kanetkar
[off-list ref]; Emil Medve [off-list ref]; Scott
Wood [off-list ref]; Rob Herring [off-list ref]; Michael
Ellerman [off-list ref]; Benjamin Herrenschmidt
[off-list ref]; netdev@vger.kernel.org;
devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; Camelia
Alexandra Groza (OSS) [off-list ref]
Subject: Re: Unsupported phy-connection-type sgmii-2500 in
arch/powerpc/boot/dts/fsl/t1023rdb.dts

quoted

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

quoted

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

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.

On Friday 04 June 2021 21:47:26 Madalin Bucur wrote:

quoted

-----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 [off-list ref]; Shruti Kanetkar
[off-list ref]; Emil Medve [off-list ref]; Scott
Wood [off-list ref]; Rob Herring [off-list ref]; Michael
Ellerman [off-list ref]; Benjamin Herrenschmidt
[off-list ref]; netdev@vger.kernel.org;
devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; Camelia
Alexandra Groza (OSS) [off-list ref]
Subject: Re: Unsupported phy-connection-type sgmii-2500 in
arch/powerpc/boot/dts/fsl/t1023rdb.dts

quoted

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

quoted

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.

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!

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:

quoted

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.

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:

quoted

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.

On 6/5/21 2:50 PM, Pali Rohár wrote:

On Saturday 05 June 2021 15:26:39 Vladimir Oltean wrote:

quoted

On Sat, Jun 05, 2021 at 01:33:07AM +0100, Russell King (Oracle) wrote:

quoted

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

quoted

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

On Saturday 05 June 2021 15:04:55 Hauke Mehrtens wrote:

On 6/5/21 2:50 PM, Pali Rohár wrote:

quoted

On Saturday 05 June 2021 15:26:39 Vladimir Oltean wrote:

quoted

On Sat, Jun 05, 2021 at 01:33:07AM +0100, Russell King (Oracle) wrote:

quoted

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

quoted

quoted

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

On 6/5/21 3:31 PM, Pali Rohár wrote:

On Saturday 05 June 2021 15:04:55 Hauke Mehrtens wrote:

quoted

On 6/5/21 2:50 PM, Pali Rohár wrote:

quoted

On Saturday 05 June 2021 15:26:39 Vladimir Oltean wrote:

quoted

On Sat, Jun 05, 2021 at 01:33:07AM +0100, Russell King (Oracle) wrote:

quoted

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

quoted

quoted

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

quoted

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.

quoted

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.

quoted

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.

quoted

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.

quoted

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

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!

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:

quoted

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!

On Saturday 05 June 2021 01:34:55 Pali Rohár wrote:

On Friday 04 June 2021 21:47:26 Madalin Bucur wrote:

quoted

quoted

-----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 [off-list ref]; Shruti Kanetkar
[off-list ref]; Emil Medve [off-list ref]; Scott
Wood [off-list ref]; Rob Herring [off-list ref]; Michael
Ellerman [off-list ref]; Benjamin Herrenschmidt
[off-list ref]; netdev@vger.kernel.org;
devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; Camelia
Alexandra Groza (OSS) [off-list ref]
Subject: Re: Unsupported phy-connection-type sgmii-2500 in
arch/powerpc/boot/dts/fsl/t1023rdb.dts

quoted

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

quoted

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?

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

On Sun, 2021-07-04 at 15:43 +0200, Pali Rohár wrote:

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

-Scott

On Wednesday 14 July 2021 12:11:49 Scott Wood wrote:

On Sun, 2021-07-04 at 15:43 +0200, Pali Rohár wrote:

quoted

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?

On Friday 27 August 2021 13:38:36 Pali Rohár wrote:

On Wednesday 14 July 2021 12:11:49 Scott Wood wrote:

quoted

On Sun, 2021-07-04 at 15:43 +0200, Pali Rohár wrote:

quoted

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.

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:

quoted

On Wednesday 14 July 2021 12:11:49 Scott Wood wrote:

quoted

On Sun, 2021-07-04 at 15:43 +0200, Pali Rohár wrote:

quoted

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 [off-list ref]
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

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:

quoted

On Friday 27 August 2021 13:38:36 Pali Rohár wrote:

quoted

On Wednesday 14 July 2021 12:11:49 Scott Wood wrote:

quoted

On Sun, 2021-07-04 at 15:43 +0200, Pali Rohár wrote:

quoted

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 [off-list ref]
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