net: phy: Dealing with 88e1543 dual-port mode

net: phy: Dealing with 88e1543 dual-port mode

[Maxime Chevallier]

Hello everyone,

I'm reaching out to discuss an issue I'm currently having, while working
on a Marvell 88E1543 PHY.

This PHY is very similar to the 88E1545 we already support upstream, but
with an added "dual-port mode" feature that I'm currently using in a
project, and that might be interesting to have upstream.

As a quick remainder, the 88E154x family are 4-ports PHYs that support
Fiber (SFP) or RJ45 Copper interfaces on the media side, and QSGMII/SGMII
on the host side.

A datasheet for this PHY family can be found here [1] but unfortunately,
this public datasheet doesn't explain the mode I'm going to discuss...

The specificity of the 88E1543 is that is can be configured as a 2-port
PHY, each port having the ability to have both a Copper RJ45 interface and
a Fiber interface with automatic media detection, very much like the
88x3310 that we support, and that is used on the MacchiatoBin.

This auto-media detection is the specific mode i'm interested in.

The way this works is that the PHY is internally configured by chaining
2 internal PHYs back to back. One PHY deals with the Host interface and
is configured as an SGMII to QSGMII converter (the QSGMII is only used
from within the PHY), and the other PHY acts as the Media-side PHY,
configured in QSGMII to auto-media (RJ45 or Fiber (SFP)) :

                +- 88e1543 -----------------------+
+-----+         | +--------+          +--------+  |  /-- Copper (RJ45)
|     |--SGMII----| Port 0 |--QSGMII--| Port 1 |----<
|     |         | +--------+          +--------+  |  \--- Fiber
| MAC |         |                                 |
|     |         | +--------+          +--------+  |  /-- Copper (RJ45)
|     |--SGMII----| Port 2 |--QSGMII--| Port 3 |----<
+-----+         | +--------+          +--------+  |  \-- Fiber
                +---------------------------------+

I have two main concerns about how to deal with that (if we are interested
in having such a support upstream at all).

The first one, is how to represent that in the DT.

One approach could be to really represents what's going on, by representing
the 2 PHYs chained together. In this case, only the MAC-facing PHY
will report the link state, so we are basically representing the internal
wiring of the PHY, can we consider that as a description of the hardware ?

Besides that, I don't think that today, we are able to represent link
composed of multiple PHYs daisy-chained together, but this is something
that we might want to support one day, since it could benefit other types
of use-cases.

Another approach could be to pretend the 88E1543 is a 2-port SGMII to
Auto-media PHY. This is also a bit tricky, since we need a way to detect
that we want the whole 4-ports PHY to act as a 2-port PHY. (or 3-port, if
we only want to use one pair of ports in that mode, and the other ports
as SGMII - Copper or SGMII - Fiber PHYs).

The second concern I have is that all of this is made even harder by the
fact that this 88E1543 PHY seems indistinguishable from the 88E1545 by
reading the PHY ID, they both report 0x01410eaX :/ I guess we would also
need some DT indication that we are in fact dealing with a 88E1543.

So I'd like you opinions on how we might want to deal with such scenarios,
and if we do want to bother supporting that at all :(

Thanks in advance,

Maxime

[1] :
https://www.marvell.com/content/dam/marvell/en/public-collateral/transceivers/marvell-phys-transceivers-alaska-88e154x-datasheet.pdf

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: net: phy: Dealing with 88e1543 dual-port mode

[Russell King - ARM Linux admin]

On Thu, Nov 19, 2020 at 03:22:46PM +0100, Maxime Chevallier wrote:
> Hello everyone,
> 
> I'm reaching out to discuss an issue I'm currently having, while working
> on a Marvell 88E1543 PHY.
> 
> This PHY is very similar to the 88E1545 we already support upstream, but
> with an added "dual-port mode" feature that I'm currently using in a
> project, and that might be interesting to have upstream.
> 
> As a quick remainder, the 88E154x family are 4-ports PHYs that support
> Fiber (SFP) or RJ45 Copper interfaces on the media side, and QSGMII/SGMII
> on the host side.
> 
> A datasheet for this PHY family can be found here [1] but unfortunately,
> this public datasheet doesn't explain the mode I'm going to discuss...
> 
> The specificity of the 88E1543 is that is can be configured as a 2-port
> PHY, each port having the ability to have both a Copper RJ45 interface and
> a Fiber interface with automatic media detection, very much like the
> 88x3310 that we support, and that is used on the MacchiatoBin.
> 
> This auto-media detection is the specific mode i'm interested in.
> 
> The way this works is that the PHY is internally configured by chaining
> 2 internal PHYs back to back. One PHY deals with the Host interface and
> is configured as an SGMII to QSGMII converter (the QSGMII is only used
> from within the PHY), and the other PHY acts as the Media-side PHY,
> configured in QSGMII to auto-media (RJ45 or Fiber (SFP)) :
> 
>                 +- 88e1543 -----------------------+
> +-----+         | +--------+          +--------+  |  /-- Copper (RJ45)
> |     |--SGMII----| Port 0 |--QSGMII--| Port 1 |----<
> |     |         | +--------+          +--------+  |  \--- Fiber
> | MAC |         |                                 |
> |     |         | +--------+          +--------+  |  /-- Copper (RJ45)
> |     |--SGMII----| Port 2 |--QSGMII--| Port 3 |----<
> +-----+         | +--------+          +--------+  |  \-- Fiber
>                 +---------------------------------+

Yes, this is somewhat like the 88x3310 - the 88x3310 PHY is actually a
collection of different PHY blocks integrated together, with a chunk of
firmware controlling the whole thing, enabling the appropriate PHY
blocks and routing the data paths amongst them as required.

With the 88x3310, we don't care very much about the MAC-facing blocks
(PHYXS in Clause 45 terminology). We certainly do not check the PHYXS
for link before reporting that the PHY as a whole has link - this is
actually very important, since with the 88x3310, we have to report to
the MAC that the link is up so the MAC can configure its PHY facing
interface correctly before that part of the link will come up.

Also, if we look at 88e1512 when used in SGMII to copper mode, this
PHY re-uses its fiber side for the MAC facing SGMII interface, so can
be regarded similar to your above diagram.

So, a question for you: does the above setup for ports 0 and 2 require
any software configuration of the PHY, or is that all achieved by
hardware strapping the PHY for the appropriate mode?

If it's all done by hardware strapping with no software configuration
requirement for ports 0 and 2, I would suggest that we ignore the
complexities here, and just represent ports 1 and 3 as normal, as a
SGMII-to-{copper,fibre}.

If we were to let phylib to drive ports 0 and 2 as well, we're going
to introduce a whole raft of entirely new problems. phylib is only
really designed for the last-step media facing PHY.

> I have two main concerns about how to deal with that (if we are interested
> in having such a support upstream at all).
> 
> The first one, is how to represent that in the DT.
> 
> One approach could be to really represents what's going on, by representing
> the 2 PHYs chained together. In this case, only the MAC-facing PHY
> will report the link state, so we are basically representing the internal
> wiring of the PHY, can we consider that as a description of the hardware ?
> 
> Besides that, I don't think that today, we are able to represent link
> composed of multiple PHYs daisy-chained together, but this is something
> that we might want to support one day, since it could benefit other types
> of use-cases.
> 
> Another approach could be to pretend the 88E1543 is a 2-port SGMII to
> Auto-media PHY. This is also a bit tricky, since we need a way to detect
> that we want the whole 4-ports PHY to act as a 2-port PHY. (or 3-port, if
> we only want to use one pair of ports in that mode, and the other ports
> as SGMII - Copper or SGMII - Fiber PHYs).

Aren't each of the four ports at a different MDIO address, which means
each has to be described separately?

> The second concern I have is that all of this is made even harder by the
> fact that this 88E1543 PHY seems indistinguishable from the 88E1545 by
> reading the PHY ID, they both report 0x01410eaX :/ I guess we would also
> need some DT indication that we are in fact dealing with a 88E1543.
> 
> So I'd like you opinions on how we might want to deal with such scenarios,
> and if we do want to bother supporting that at all :(
> 
> Thanks in advance,
> 
> Maxime
> 
> [1] :
> https://www.marvell.com/content/dam/marvell/en/public-collateral/transceivers/marvell-phys-transceivers-alaska-88e154x-datasheet.pdf
> 

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: net: phy: Dealing with 88e1543 dual-port mode

[Russell King - ARM Linux admin]

On Thu, Nov 19, 2020 at 02:55:00PM +0000, Russell King - ARM Linux admin wrote:
> On Thu, Nov 19, 2020 at 03:22:46PM +0100, Maxime Chevallier wrote:
> > Hello everyone,
> > 
> > I'm reaching out to discuss an issue I'm currently having, while working
> > on a Marvell 88E1543 PHY.
> > 
> > This PHY is very similar to the 88E1545 we already support upstream, but
> > with an added "dual-port mode" feature that I'm currently using in a
> > project, and that might be interesting to have upstream.
> > 
> > As a quick remainder, the 88E154x family are 4-ports PHYs that support
> > Fiber (SFP) or RJ45 Copper interfaces on the media side, and QSGMII/SGMII
> > on the host side.
> > 
> > A datasheet for this PHY family can be found here [1] but unfortunately,
> > this public datasheet doesn't explain the mode I'm going to discuss...
> > 
> > The specificity of the 88E1543 is that is can be configured as a 2-port
> > PHY, each port having the ability to have both a Copper RJ45 interface and
> > a Fiber interface with automatic media detection, very much like the
> > 88x3310 that we support, and that is used on the MacchiatoBin.
> > 
> > This auto-media detection is the specific mode i'm interested in.
> > 
> > The way this works is that the PHY is internally configured by chaining
> > 2 internal PHYs back to back. One PHY deals with the Host interface and
> > is configured as an SGMII to QSGMII converter (the QSGMII is only used
> > from within the PHY), and the other PHY acts as the Media-side PHY,
> > configured in QSGMII to auto-media (RJ45 or Fiber (SFP)) :
> > 
> >                 +- 88e1543 -----------------------+
> > +-----+         | +--------+          +--------+  |  /-- Copper (RJ45)
> > |     |--SGMII----| Port 0 |--QSGMII--| Port 1 |----<
> > |     |         | +--------+          +--------+  |  \--- Fiber
> > | MAC |         |                                 |
> > |     |         | +--------+          +--------+  |  /-- Copper (RJ45)
> > |     |--SGMII----| Port 2 |--QSGMII--| Port 3 |----<
> > +-----+         | +--------+          +--------+  |  \-- Fiber
> >                 +---------------------------------+
> 
> Yes, this is somewhat like the 88x3310 - the 88x3310 PHY is actually a
> collection of different PHY blocks integrated together, with a chunk of
> firmware controlling the whole thing, enabling the appropriate PHY
> blocks and routing the data paths amongst them as required.
> 
> With the 88x3310, we don't care very much about the MAC-facing blocks
> (PHYXS in Clause 45 terminology). We certainly do not check the PHYXS
> for link before reporting that the PHY as a whole has link - this is
> actually very important, since with the 88x3310, we have to report to
> the MAC that the link is up so the MAC can configure its PHY facing
> interface correctly before that part of the link will come up.
> 
> Also, if we look at 88e1512 when used in SGMII to copper mode, this
> PHY re-uses its fiber side for the MAC facing SGMII interface, so can
> be regarded similar to your above diagram.
> 
> So, a question for you: does the above setup for ports 0 and 2 require
> any software configuration of the PHY, or is that all achieved by
> hardware strapping the PHY for the appropriate mode?
> 
> If it's all done by hardware strapping with no software configuration
> requirement for ports 0 and 2, I would suggest that we ignore the
> complexities here, and just represent ports 1 and 3 as normal, as a
> SGMII-to-{copper,fibre}.
> 
> If we were to let phylib to drive ports 0 and 2 as well, we're going
> to introduce a whole raft of entirely new problems. phylib is only
> really designed for the last-step media facing PHY.
> 
> > I have two main concerns about how to deal with that (if we are interested
> > in having such a support upstream at all).
> > 
> > The first one, is how to represent that in the DT.
> > 
> > One approach could be to really represents what's going on, by representing
> > the 2 PHYs chained together. In this case, only the MAC-facing PHY
> > will report the link state, so we are basically representing the internal
> > wiring of the PHY, can we consider that as a description of the hardware ?
> > 
> > Besides that, I don't think that today, we are able to represent link
> > composed of multiple PHYs daisy-chained together, but this is something
> > that we might want to support one day, since it could benefit other types
> > of use-cases.
> > 
> > Another approach could be to pretend the 88E1543 is a 2-port SGMII to
> > Auto-media PHY. This is also a bit tricky, since we need a way to detect
> > that we want the whole 4-ports PHY to act as a 2-port PHY. (or 3-port, if
> > we only want to use one pair of ports in that mode, and the other ports
> > as SGMII - Copper or SGMII - Fiber PHYs).
> 
> Aren't each of the four ports at a different MDIO address, which means
> each has to be described separately?
> 
> > The second concern I have is that all of this is made even harder by the
> > fact that this 88E1543 PHY seems indistinguishable from the 88E1545 by
> > reading the PHY ID, they both report 0x01410eaX :/ I guess we would also
> > need some DT indication that we are in fact dealing with a 88E1543.

Note that it'll need slightly different initialisation paths, separate
from the 88E151x. If we're in PHY_INTERFACE_MODE_SGMII, we don't look
at the fiber page (for the reason I mentioned above - it's re-used for
the MAC facing side of the PHY.)

Also, yes, I realise that this doesn't conform to "DT describes the
hardware". It's a question of how detailed a description we actually
need. DT is not a schematic tool - it hasn't ever been used to describe
everything at the hardware. It is a software representation of the
hardware components in the system needed to be driven by software.

If a component does not need to be driven by software, arguably it
doesn't need to be mentioned in the DT description of the hardware.

Consider a PCI(e) card. It's treated as a black hardware box as far
as firmware descriptions go, even if we know the hardware consists of
an Ethernet device and a separate PHY.

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: net: phy: Dealing with 88e1543 dual-port mode

[Maxime Chevallier]

Hello Russell,

On Thu, 19 Nov 2020 14:55:00 +0000
Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote:

>On Thu, Nov 19, 2020 at 03:22:46PM +0100, Maxime Chevallier wrote:
>> Hello everyone,
>> 
>> I'm reaching out to discuss an issue I'm currently having, while working
>> on a Marvell 88E1543 PHY.
>> 
>> This PHY is very similar to the 88E1545 we already support upstream, but
>> with an added "dual-port mode" feature that I'm currently using in a
>> project, and that might be interesting to have upstream.
>> 
>> As a quick remainder, the 88E154x family are 4-ports PHYs that support
>> Fiber (SFP) or RJ45 Copper interfaces on the media side, and QSGMII/SGMII
>> on the host side.
>> 
>> A datasheet for this PHY family can be found here [1] but unfortunately,
>> this public datasheet doesn't explain the mode I'm going to discuss...
>> 
>> The specificity of the 88E1543 is that is can be configured as a 2-port
>> PHY, each port having the ability to have both a Copper RJ45 interface and
>> a Fiber interface with automatic media detection, very much like the
>> 88x3310 that we support, and that is used on the MacchiatoBin.
>> 
>> This auto-media detection is the specific mode i'm interested in.
>> 
>> The way this works is that the PHY is internally configured by chaining
>> 2 internal PHYs back to back. One PHY deals with the Host interface and
>> is configured as an SGMII to QSGMII converter (the QSGMII is only used
>> from within the PHY), and the other PHY acts as the Media-side PHY,
>> configured in QSGMII to auto-media (RJ45 or Fiber (SFP)) :
>> 
>>                 +- 88e1543 -----------------------+
>> +-----+         | +--------+          +--------+  |  /-- Copper (RJ45)
>> |     |--SGMII----| Port 0 |--QSGMII--| Port 1 |----<
>> |     |         | +--------+          +--------+  |  \--- Fiber
>> | MAC |         |                                 |
>> |     |         | +--------+          +--------+  |  /-- Copper (RJ45)
>> |     |--SGMII----| Port 2 |--QSGMII--| Port 3 |----<
>> +-----+         | +--------+          +--------+  |  \-- Fiber
>>                 +---------------------------------+  
>
>Yes, this is somewhat like the 88x3310 - the 88x3310 PHY is actually a
>collection of different PHY blocks integrated together, with a chunk of
>firmware controlling the whole thing, enabling the appropriate PHY
>blocks and routing the data paths amongst them as required.
>
>With the 88x3310, we don't care very much about the MAC-facing blocks
>(PHYXS in Clause 45 terminology). We certainly do not check the PHYXS
>for link before reporting that the PHY as a whole has link - this is
>actually very important, since with the 88x3310, we have to report to
>the MAC that the link is up so the MAC can configure its PHY facing
>interface correctly before that part of the link will come up.
>
>Also, if we look at 88e1512 when used in SGMII to copper mode, this
>PHY re-uses its fiber side for the MAC facing SGMII interface, so can
>be regarded similar to your above diagram.
>
>So, a question for you: does the above setup for ports 0 and 2 require
>any software configuration of the PHY, or is that all achieved by
>hardware strapping the PHY for the appropriate mode?
>
>If it's all done by hardware strapping with no software configuration
>requirement for ports 0 and 2, I would suggest that we ignore the
>complexities here, and just represent ports 1 and 3 as normal, as a
>SGMII-to-{copper,fibre}.

I gave it a look, and indeed ports 0 and 2 don't need any particular
software configuration, all the config is done on ports 1 and 3. So,
you're right this simplifies a lot the situation :)

There's one thing though, ports 1 and 3 can be used as
SGMII-to-Copper, SGMII-to-Fibre (in that case, ports 0 and 2 are
also available to use), or as SGMII-to-{Copper + Fibre} with
autodetection, in that case ports 0/2 act as the MAC facing side.

In the latter case, we need to configure a few registers on port 1/3 to
configure the internal circuitry. (but we do leave ports 0/2 untouched).

I don't think we have a way to distinguish from the DT if we are in
SGMII-to-Fibre or in SGMII-to-{Copper + Fibre}, since the description is
the same, we don't have any information in DT about wether or not the
PHY is wired to a Copper RJ45 port.

Maybe we should have a way to indicate if a PHY is wired to a Copper
port in DT ?

>If we were to let phylib to drive ports 0 and 2 as well, we're going
>to introduce a whole raft of entirely new problems. phylib is only
>really designed for the last-step media facing PHY.
>
>> I have two main concerns about how to deal with that (if we are interested
>> in having such a support upstream at all).
>> 
>> The first one, is how to represent that in the DT.
>> 
>> One approach could be to really represents what's going on, by representing
>> the 2 PHYs chained together. In this case, only the MAC-facing PHY
>> will report the link state, so we are basically representing the internal
>> wiring of the PHY, can we consider that as a description of the hardware ?
>> 
>> Besides that, I don't think that today, we are able to represent link
>> composed of multiple PHYs daisy-chained together, but this is something
>> that we might want to support one day, since it could benefit other types
>> of use-cases.
>> 
>> Another approach could be to pretend the 88E1543 is a 2-port SGMII to
>> Auto-media PHY. This is also a bit tricky, since we need a way to detect
>> that we want the whole 4-ports PHY to act as a 2-port PHY. (or 3-port, if
>> we only want to use one pair of ports in that mode, and the other ports
>> as SGMII - Copper or SGMII - Fiber PHYs).  
>
>Aren't each of the four ports at a different MDIO address, which means
>each has to be described separately?

Yes indeed

>> The second concern I have is that all of this is made even harder by the
>> fact that this 88E1543 PHY seems indistinguishable from the 88E1545 by
>> reading the PHY ID, they both report 0x01410eaX :/ I guess we would also
>> need some DT indication that we are in fact dealing with a 88E1543.
>> 
>> So I'd like you opinions on how we might want to deal with such scenarios,
>> and if we do want to bother supporting that at all :(
>> 
>> Thanks in advance,
>> 
>> Maxime
>> 
>> [1] :
>> https://www.marvell.com/content/dam/marvell/en/public-collateral/transceivers/marvell-phys-transceivers-alaska-88e154x-datasheet.pdf
>>   
>



-- 
Maxime Chevallier, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: net: phy: Dealing with 88e1543 dual-port mode

[Tobias Waldekranz]

On Thu, Nov 19, 2020 at 16:24, Maxime Chevallier <maxime.chevallier@bootlin.com> wrote:
> I don't think we have a way to distinguish from the DT if we are in
> SGMII-to-Fibre or in SGMII-to-{Copper + Fibre}, since the description is
> the same, we don't have any information in DT about wether or not the
> PHY is wired to a Copper RJ45 port.
>
> Maybe we should have a way to indicate if a PHY is wired to a Copper
> port in DT ?

Do you mean something like:

SGMII->SGMII (Fibre):
ethernet-phy@0 {
   sfp = <&sfp0>;
};

SGMII->MDI (Copper):
ethernet-phy@0 {
    mdi;
};

SGMII->Auto Media Detect
ethernet-phy@0 {
    mdi;
    sfp = <&sfp0>;
};

If so, this could also be useful in scenarios that have nothing to do
with combo ports, but where you have custom connectors.

E.g. at Westermo we make switches with M12/M12X connectors [1] that
sometimes have a 1G PHY behind a 2-pair M12 connector (for complicated
legacy reasons). In such cases we have to remove 1000-HD/FD from the
advertised link modes. Being able to describe that in the DT with
something like:

ethernet-phy@0 {
    mdi = "2-pair";
};

Would be great!

On the topic of combo ports, another thing to consider is how this
should play with ethtool. Ideally it would be aware of the two media
sides, and be able to configure them both independently.

[1]: https://www.westermo.com/products/ethernet-switches/en50155/viper-208-t4g-tbn

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: net: phy: Dealing with 88e1543 dual-port mode

[Russell King - ARM Linux admin]

On Thu, Nov 19, 2020 at 11:43:39PM +0100, Tobias Waldekranz wrote:
> On Thu, Nov 19, 2020 at 16:24, Maxime Chevallier <maxime.chevallier@bootlin.com> wrote:
> > I don't think we have a way to distinguish from the DT if we are in
> > SGMII-to-Fibre or in SGMII-to-{Copper + Fibre}, since the description is
> > the same, we don't have any information in DT about wether or not the
> > PHY is wired to a Copper RJ45 port.
> >
> > Maybe we should have a way to indicate if a PHY is wired to a Copper
> > port in DT ?
> 
> Do you mean something like:
> 
> SGMII->SGMII (Fibre):
> ethernet-phy@0 {
>    sfp = <&sfp0>;
> };
> 
> SGMII->MDI (Copper):
> ethernet-phy@0 {
>     mdi;
> };
> 
> SGMII->Auto Media Detect
> ethernet-phy@0 {
>     mdi;
>     sfp = <&sfp0>;
> };

This isn't something we could realistically do - think about how many
DT files are out there today which would not have this for an existing
PHY. The default has to be that today's DT descriptions continue to work
as-is, and that includes ones which already support copper and fibre
either with or without a sfp property.

So, we can't draw any conclusion about whether the fiber interface is
wired from whether there is a sfp property or not.

We also can't draw a conclusion about whether the copper side is wired
using a "mdi" property, or whether there is a "sfp" property or not.

The only thing we could realistically do today is to introduce a
property like:

	mdi = "disabled" | "okay";

to indicate whether the copper port can be used, and maybe something
similar for the fiber interface.  Maybe as you suggest, not "okay"
but specifying the number of connected pairs would be a good idea,
or maybe that should be a separate property?

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: net: phy: Dealing with 88e1543 dual-port mode

[Tobias Waldekranz]

On Thu, Nov 19, 2020 at 23:16, Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote:
> On Thu, Nov 19, 2020 at 11:43:39PM +0100, Tobias Waldekranz wrote:
>> On Thu, Nov 19, 2020 at 16:24, Maxime Chevallier <maxime.chevallier@bootlin.com> wrote:
>> > I don't think we have a way to distinguish from the DT if we are in
>> > SGMII-to-Fibre or in SGMII-to-{Copper + Fibre}, since the description is
>> > the same, we don't have any information in DT about wether or not the
>> > PHY is wired to a Copper RJ45 port.
>> >
>> > Maybe we should have a way to indicate if a PHY is wired to a Copper
>> > port in DT ?
>> 
>> Do you mean something like:
>> 
>> SGMII->SGMII (Fibre):
>> ethernet-phy@0 {
>>    sfp = <&sfp0>;
>> };
>> 
>> SGMII->MDI (Copper):
>> ethernet-phy@0 {
>>     mdi;
>> };
>> 
>> SGMII->Auto Media Detect
>> ethernet-phy@0 {
>>     mdi;
>>     sfp = <&sfp0>;
>> };
>
> This isn't something we could realistically do - think about how many
> DT files are out there today which would not have this for an existing
> PHY. The default has to be that today's DT descriptions continue to work
> as-is, and that includes ones which already support copper and fibre
> either with or without a sfp property.
>
> So, we can't draw any conclusion about whether the fiber interface is
> wired from whether there is a sfp property or not.
>
> We also can't draw a conclusion about whether the copper side is wired
> using a "mdi" property, or whether there is a "sfp" property or not.
>
> The only thing we could realistically do today is to introduce a
> property like:
>
> 	mdi = "disabled" | "okay";
>
> to indicate whether the copper port can be used, and maybe something
> similar for the fiber interface.  Maybe as you suggest, not "okay"
> but specifying the number of connected pairs would be a good idea,
> or maybe that should be a separate property?

Maybe you could have optional media nodes under the PHY instead, so that
you don't involve the SFP property in the logic (SGMII can be connected
to lots of things after all):

    ethernet-phy@0 {
        ...

        sgmii {
            status = "okay";
            preferred;
        };

        mdi {
           status = "okay";
           pairs = <2>;
        };
    };

In the absence of any media declarations, you fall back to the driver's
default behavior (keeping compatibility with older DTs). But you can
still add support for more configurations if the information is
available.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: net: phy: Dealing with 88e1543 dual-port mode

[Russell King - ARM Linux admin]

On Fri, Nov 20, 2020 at 01:11:12AM +0100, Tobias Waldekranz wrote:
> On Thu, Nov 19, 2020 at 23:16, Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote:
> > On Thu, Nov 19, 2020 at 11:43:39PM +0100, Tobias Waldekranz wrote:
> >> On Thu, Nov 19, 2020 at 16:24, Maxime Chevallier <maxime.chevallier@bootlin.com> wrote:
> >> > I don't think we have a way to distinguish from the DT if we are in
> >> > SGMII-to-Fibre or in SGMII-to-{Copper + Fibre}, since the description is
> >> > the same, we don't have any information in DT about wether or not the
> >> > PHY is wired to a Copper RJ45 port.
> >> >
> >> > Maybe we should have a way to indicate if a PHY is wired to a Copper
> >> > port in DT ?
> >> 
> >> Do you mean something like:
> >> 
> >> SGMII->SGMII (Fibre):
> >> ethernet-phy@0 {
> >>    sfp = <&sfp0>;
> >> };
> >> 
> >> SGMII->MDI (Copper):
> >> ethernet-phy@0 {
> >>     mdi;
> >> };
> >> 
> >> SGMII->Auto Media Detect
> >> ethernet-phy@0 {
> >>     mdi;
> >>     sfp = <&sfp0>;
> >> };
> >
> > This isn't something we could realistically do - think about how many
> > DT files are out there today which would not have this for an existing
> > PHY. The default has to be that today's DT descriptions continue to work
> > as-is, and that includes ones which already support copper and fibre
> > either with or without a sfp property.
> >
> > So, we can't draw any conclusion about whether the fiber interface is
> > wired from whether there is a sfp property or not.
> >
> > We also can't draw a conclusion about whether the copper side is wired
> > using a "mdi" property, or whether there is a "sfp" property or not.
> >
> > The only thing we could realistically do today is to introduce a
> > property like:
> >
> > 	mdi = "disabled" | "okay";
> >
> > to indicate whether the copper port can be used, and maybe something
> > similar for the fiber interface.  Maybe as you suggest, not "okay"
> > but specifying the number of connected pairs would be a good idea,
> > or maybe that should be a separate property?
> 
> Maybe you could have optional media nodes under the PHY instead, so that
> you don't involve the SFP property in the logic (SGMII can be connected
> to lots of things after all):

I think you're advocating calling the fiber interface "SGMII", which
would be totally wrong.

SGMII is a Cisco modification of 802.3 1000base-X to allow 10M and 100M
speeds to be used over a single serdes lane in each direction.

1000base-X is what you run over a fiber link. This is not SGMII. Using
"SGMII" for 1000base-X is incorrect, but a common abuse of the term in
industry. Abusing a term does not make it correct, especially when it
comes to defining further standards.

(This is one of my pet peaves, sorry.)

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: net: phy: Dealing with 88e1543 dual-port mode

[Tobias Waldekranz]

On Fri, Nov 20, 2020 at 00:40, Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote:
> I think you're advocating calling the fiber interface "SGMII", which
> would be totally wrong.
>
> SGMII is a Cisco modification of 802.3 1000base-X to allow 10M and 100M
> speeds to be used over a single serdes lane in each direction.
>
> 1000base-X is what you run over a fiber link. This is not SGMII. Using
> "SGMII" for 1000base-X is incorrect, but a common abuse of the term in
> industry. Abusing a term does not make it correct, especially when it
> comes to defining further standards.
>
> (This is one of my pet peaves, sorry.)

Nomenclature is very important, no excuse necessary.

You are right that SGMII is not the term I am looking for, but I am not
sure 1000base-X is either. I am looking for a word that describes the
serial interface that can run in either 1000base-X or 100base-FX mode
(and possibly other ancient/proprietary modes). Maybe just "serdes"?

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: net: phy: Dealing with 88e1543 dual-port mode

[Maxime Chevallier]

Hi Tobias,

On Fri, 20 Nov 2020 01:11:12 +0100
Tobias Waldekranz <tobias@waldekranz.com> wrote:

>On Thu, Nov 19, 2020 at 23:16, Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote:
>> On Thu, Nov 19, 2020 at 11:43:39PM +0100, Tobias Waldekranz wrote:  
>>> On Thu, Nov 19, 2020 at 16:24, Maxime Chevallier <maxime.chevallier@bootlin.com> wrote:  
>>> > I don't think we have a way to distinguish from the DT if we are in
>>> > SGMII-to-Fibre or in SGMII-to-{Copper + Fibre}, since the description is
>>> > the same, we don't have any information in DT about wether or not the
>>> > PHY is wired to a Copper RJ45 port.
>>> >
>>> > Maybe we should have a way to indicate if a PHY is wired to a Copper
>>> > port in DT ?  
>>> 
>>> Do you mean something like:
>>> 
>>> SGMII->SGMII (Fibre):
>>> ethernet-phy@0 {
>>>    sfp = <&sfp0>;
>>> };
>>> 
>>> SGMII->MDI (Copper):
>>> ethernet-phy@0 {
>>>     mdi;
>>> };
>>> 
>>> SGMII->Auto Media Detect
>>> ethernet-phy@0 {
>>>     mdi;
>>>     sfp = <&sfp0>;
>>> };  
>>
>> This isn't something we could realistically do - think about how many
>> DT files are out there today which would not have this for an existing
>> PHY. The default has to be that today's DT descriptions continue to work
>> as-is, and that includes ones which already support copper and fibre
>> either with or without a sfp property.
>>
>> So, we can't draw any conclusion about whether the fiber interface is
>> wired from whether there is a sfp property or not.
>>
>> We also can't draw a conclusion about whether the copper side is wired
>> using a "mdi" property, or whether there is a "sfp" property or not.
>>
>> The only thing we could realistically do today is to introduce a
>> property like:
>>
>> 	mdi = "disabled" | "okay";
>>
>> to indicate whether the copper port can be used, and maybe something
>> similar for the fiber interface.  Maybe as you suggest, not "okay"
>> but specifying the number of connected pairs would be a good idea,
>> or maybe that should be a separate property?  
>
>Maybe you could have optional media nodes under the PHY instead, so that
>you don't involve the SFP property in the logic (SGMII can be connected
>to lots of things after all):
>
>    ethernet-phy@0 {
>        ...
>
>        sgmii {
>            status = "okay";
>            preferred;
>        };
>
>        mdi {
>           status = "okay";
>           pairs = <2>;
>        };
>    };

I like that approach too, and I agree that we do need to be very careful
with not breaking existing PHYs, where most of the time we assume that
a PHY simply has a 8P8C (RJ45) connector.

Maybe the term MDI is a bit misused here, my understanding was that MDI,
standing for "Media Dependent Interface" represents the media-side
interface in general, and not a particular technology such as
xxxBaseT/X/K or Copper of Fibre.

So maybe we could be a bit more generic, with something along these lines :

    ethernet-phy@0 {
        ...

        mdi {
            port@0 {
                media = "10baseT", "100baseT", "1000baseT";
                pairs = <1>;
	    };

            port@1 {
                media = "1000baseX", "10gbaseR"
            };
        };
    };

This would allow us to explicitely indicate which modes are supported
by each port.

And in absence of the mdi node, we indeed fallback to the usual behaviour.

>In the absence of any media declarations, you fall back to the driver's
>default behavior (keeping compatibility with older DTs). But you can
>still add support for more configurations if the information is
>available.

I also like the idea of having a way to express the "preferred" media,
although I wonder if that's something we want to include in DT or that
we would want to tweak at runtime, through ethtool for example.

What do you think ?

Thanks,

Maxime


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: net: phy: Dealing with 88e1543 dual-port mode

[Russell King - ARM Linux admin]

On Fri, Nov 20, 2020 at 10:36:01AM +0100, Maxime Chevallier wrote:
> So maybe we could be a bit more generic, with something along these lines :
> 
>     ethernet-phy@0 {
>         ...
> 
>         mdi {
>             port@0 {
>                 media = "10baseT", "100baseT", "1000baseT";
>                 pairs = <1>;
> 	    };
> 
>             port@1 {
>                 media = "1000baseX", "10gbaseR"
>             };
>         };
>     };

Don't forget that TP requires a minimum of two pairs. However, as
Andrew pointed out, we already have max-speed which can be used to
limit the speed below that which requires four pairs.

I have untested patches that allow the 88x3310 to be reconfigured
between 10GBASE-R and 1000BASE-X depending on the SFP connected -
untested because the I2C pull-ups on the Macchiatobin boards I have
are way too strong and it results in SFP EEPROM corruption and/or
failure to read the EEPROM.

> I also like the idea of having a way to express the "preferred" media,
> although I wonder if that's something we want to include in DT or that
> we would want to tweak at runtime, through ethtool for example.

I think preferred media should be configurable through ethtool -
which is preferred will be specific to the user's application.
However, there may be scope for DT to be able to specify the default
preferred media.

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: net: phy: Dealing with 88e1543 dual-port mode

[Tobias Waldekranz]

On Fri, Nov 20, 2020 at 10:25, Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote:
> On Fri, Nov 20, 2020 at 10:36:01AM +0100, Maxime Chevallier wrote:
>> So maybe we could be a bit more generic, with something along these lines :
>> 
>>     ethernet-phy@0 {
>>         ...
>> 
>>         mdi {
>>             port@0 {
>>                 media = "10baseT", "100baseT", "1000baseT";
>>                 pairs = <1>;
>> 	    };
>> 
>>             port@1 {
>>                 media = "1000baseX", "10gbaseR"
>>             };
>>         };
>>     };

Yeah that looks even better. Though "pairs" is redundant if you can
specify the list of supported link modes. I guess not specifying "media"
should mean "use all modes supported by the PHY". And if, for example,
media is set to 10-T+100-TX, that means that only two pairs will be
used.

> Don't forget that TP requires a minimum of two pairs. However, as
> Andrew pointed out, we already have max-speed which can be used to
> limit the speed below that which requires four pairs.

Maybe "max-speed" is how you solve this in the absense of explicit an
MDI declaration? Because in the multi-port case, the setting could be
different for the two ports, so you would source the information from
the "media" property instead.

> I have untested patches that allow the 88x3310 to be reconfigured
> between 10GBASE-R and 1000BASE-X depending on the SFP connected -
> untested because the I2C pull-ups on the Macchiatobin boards I have
> are way too strong and it results in SFP EEPROM corruption and/or
> failure to read the EEPROM.
>
>> I also like the idea of having a way to express the "preferred" media,
>> although I wonder if that's something we want to include in DT or that
>> we would want to tweak at runtime, through ethtool for example.
>
> I think preferred media should be configurable through ethtool -
> which is preferred will be specific to the user's application.

Yeah I half-regretted putting that in there right after I hit "send" :)
It should definitely be configurable from ethtool.

> However, there may be scope for DT to be able to specify the default
> preferred media.

This is where I was coming from. The vendor could potentially have more
information on what the default should be. But I guess you could also
argue that there is value in having Linux behave the same across all
devices.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: net: phy: Dealing with 88e1543 dual-port mode

[Andrew Lunn]

On Fri, Nov 20, 2020 at 10:25:38AM +0000, Russell King - ARM Linux admin wrote:
> On Fri, Nov 20, 2020 at 10:36:01AM +0100, Maxime Chevallier wrote:
> > So maybe we could be a bit more generic, with something along these lines :
> > 
> >     ethernet-phy@0 {
> >         ...
> > 
> >         mdi {
> >             port@0 {
> >                 media = "10baseT", "100baseT", "1000baseT";
> >                 pairs = <1>;
> > 	    };
> > 
> >             port@1 {
> >                 media = "1000baseX", "10gbaseR"
> >             };
> >         };
> >     };
> 
> Don't forget that TP requires a minimum of two pairs.

Hi Russell

Well, actually, there are automotive PHYs which use just one pair, so
called T1 PHYs. We have drivers for i think two so far, with one more
on the way.

You also have to watch out for 'clever' PHYs. The Aquantia PHY can do
1000Base-T2, i.e. 1G over two pairs. This might be a proprietary
extension, rather than standardized, but it shows it can be done. So
you have to be careful about assumptions based on the number of pairs.

    Andrew

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: net: phy: Dealing with 88e1543 dual-port mode

[Maxime Chevallier]

Hi Russell, Andrew,

On Fri, 20 Nov 2020 14:55:17 +0100
Andrew Lunn <andrew@lunn.ch> wrote:

>On Fri, Nov 20, 2020 at 10:25:38AM +0000, Russell King - ARM Linux admin wrote:
>> On Fri, Nov 20, 2020 at 10:36:01AM +0100, Maxime Chevallier wrote:  
>> > So maybe we could be a bit more generic, with something along these lines :
>> > 
>> >     ethernet-phy@0 {
>> >         ...
>> > 
>> >         mdi {
>> >             port@0 {
>> >                 media = "10baseT", "100baseT", "1000baseT";
>> >                 pairs = <1>;
>> > 	    };
>> > 
>> >             port@1 {
>> >                 media = "1000baseX", "10gbaseR"
>> >             };
>> >         };
>> >     };  
>> 
>> Don't forget that TP requires a minimum of two pairs.  
>
>Hi Russell
>
>Well, actually, there are automotive PHYs which use just one pair, so
>called T1 PHYs. We have drivers for i think two so far, with one more
>on the way.
>
>You also have to watch out for 'clever' PHYs. The Aquantia PHY can do
>1000Base-T2, i.e. 1G over two pairs. This might be a proprietary
>extension, rather than standardized, but it shows it can be done. So
>you have to be careful about assumptions based on the number of pairs.

You're right that the "pairs" property might not be needed, if we
have an appropriate media string for each mode ( maybe "1000baseT1" and
"1000baseT2" for the 2 modes you're referencing ? ).

I can also see other use-cases where having an indication of the nature
of the media interface we want to use for a PHY can be useful.

If the overall idea of having such a representation of the mdi info is
something that you can see being adopted, I'll work on a first draft
implementation to see what this looks like.

Thanks for you inputs !

Maxime

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: net: phy: Dealing with 88e1543 dual-port mode

[Andrew Lunn]

> E.g. at Westermo we make switches with M12/M12X connectors [1] that
> sometimes have a 1G PHY behind a 2-pair M12 connector (for complicated
> legacy reasons). In such cases we have to remove 1000-HD/FD from the
> advertised link modes. Being able to describe that in the DT with
> something like:
> 
> ethernet-phy@0 {
>     mdi = "2-pair";
> };

We already have a max-speed property which could be used to do this.
It will remove the 1000-HD/FD from the link mode if you set it to 100.

   Andrew

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: net: phy: Dealing with 88e1543 dual-port mode

[Tobias Waldekranz]

On Fri, Nov 20, 2020 at 01:00, Andrew Lunn <andrew@lunn.ch> wrote:
>> E.g. at Westermo we make switches with M12/M12X connectors [1] that
>> sometimes have a 1G PHY behind a 2-pair M12 connector (for complicated
>> legacy reasons). In such cases we have to remove 1000-HD/FD from the
>> advertised link modes. Being able to describe that in the DT with
>> something like:
>> 
>> ethernet-phy@0 {
>>     mdi = "2-pair";
>> };
>
> We already have a max-speed property which could be used to do this.
> It will remove the 1000-HD/FD from the link mode if you set it to 100.
>
>    Andrew

Oh wow, well strike that argument then :)

Thank you

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: net: phy: Dealing with 88e1543 dual-port mode

[Andrew Lunn]

Hi Maxime

> The way this works is that the PHY is internally configured by chaining
> 2 internal PHYs back to back. One PHY deals with the Host interface and
> is configured as an SGMII to QSGMII converter (the QSGMII is only used
> from within the PHY), and the other PHY acts as the Media-side PHY,
> configured in QSGMII to auto-media (RJ45 or Fiber (SFP)) :
> 
>                 +- 88e1543 -----------------------+
> +-----+         | +--------+          +--------+  |  /-- Copper (RJ45)
> |     |--SGMII----| Port 0 |--QSGMII--| Port 1 |----<
> |     |         | +--------+          +--------+  |  \--- Fiber
> | MAC |         |                                 |
> |     |         | +--------+          +--------+  |  /-- Copper (RJ45)
> |     |--SGMII----| Port 2 |--QSGMII--| Port 3 |----<
> +-----+         | +--------+          +--------+  |  \-- Fiber
>                 +---------------------------------+

Does this mean you need a dual port MAC as well?

Do we need to configure the MUX in the MAC?

	  Andrew

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: net: phy: Dealing with 88e1543 dual-port mode

[Maxime Chevallier]

Hi Andrew,

On Thu, 19 Nov 2020 16:16:41 +0100
Andrew Lunn <andrew@lunn.ch> wrote:

>Hi Maxime
>
>> The way this works is that the PHY is internally configured by chaining
>> 2 internal PHYs back to back. One PHY deals with the Host interface and
>> is configured as an SGMII to QSGMII converter (the QSGMII is only used
>> from within the PHY), and the other PHY acts as the Media-side PHY,
>> configured in QSGMII to auto-media (RJ45 or Fiber (SFP)) :
>> 
>>                 +- 88e1543 -----------------------+
>> +-----+         | +--------+          +--------+  |  /-- Copper (RJ45)
>> |     |--SGMII----| Port 0 |--QSGMII--| Port 1 |----<
>> |     |         | +--------+          +--------+  |  \--- Fiber
>> | MAC |         |                                 |
>> |     |         | +--------+          +--------+  |  /-- Copper (RJ45)
>> |     |--SGMII----| Port 2 |--QSGMII--| Port 3 |----<
>> +-----+         | +--------+          +--------+  |  \-- Fiber
>>                 +---------------------------------+  
>
>Does this mean you need a dual port MAC as well?
>
>Do we need to configure the MUX in the MAC?

No, it's my schematic that is misleading in that case :) The 2
ports are independent of each other. There isn't any configuration on
the MAC part for that setup.

Thanks,

Maxime



-- 
Maxime Chevallier, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel