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

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!

Powered by blists - more mailing lists