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!
