Date:   Thu, 19 Nov 2020 14:55:00 +0000
From:   Russell King - ARM Linux admin <linux@...linux.org.uk>
To:     Maxime Chevallier <maxime.chevallier@...tlin.com>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Antoine Tenart <atenart@...nel.org>,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
        netdev@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: net: phy: Dealing with 88e1543 dual-port mode

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!

Powered by blists - more mailing lists