RE: [EXT] Re: [PATCH net-next 2/9] dt-bindings: net: add backplane dt bindings

[Madalin Bucur (OSS)]

> -----Original Message-----
> From: netdev-owner@xxxxxxxxxxxxxxx <netdev-owner@xxxxxxxxxxxxxxx> On
> Behalf Of Russell King - ARM Linux admin
> Sent: Friday, March 27, 2020 7:35 PM
> To: Andrew Lunn <andrew@xxxxxxx>
> Cc: Florinel Iordache <florinel.iordache@xxxxxxx>; davem@xxxxxxxxxxxxx;
> netdev@xxxxxxxxxxxxxxx; f.fainelli@xxxxxxxxx; hkallweit1@xxxxxxxxx;
> devicetree@xxxxxxxxxxxxxxx; linux-doc@xxxxxxxxxxxxxxx; robh+dt@xxxxxxxxxx;
> mark.rutland@xxxxxxx; kuba@xxxxxxxxxx; corbet@xxxxxxx;
> shawnguo@xxxxxxxxxx; Leo Li <leoyang.li@xxxxxxx>; Madalin Bucur (OSS)
> <madalin.bucur@xxxxxxxxxxx>; Ioana Ciornei <ioana.ciornei@xxxxxxx>; linux-
> kernel@xxxxxxxxxxxxxxx
> Subject: Re: [EXT] Re: [PATCH net-next 2/9] dt-bindings: net: add
> backplane dt bindings
> 
> On Fri, Mar 27, 2020 at 04:44:48PM +0100, Andrew Lunn wrote:
> > > What worries me is the situation which I've been working on, where
> > > we want access to the PCS PHYs, and we can't have the PCS PHYs
> > > represented as a phylib PHY because we may have a copper PHY behind
> > > the PCS PHY, and we want to be talking to the copper PHY in the
> > > first instance (the PCS PHY effectivel ybecomes a slave to the
> > > copper PHY.)
> >
> > I guess we need to clarify what KR actually means. If we have a
> > backplane with a MAC on each end, i think modelling it as a PHY could
> > work.
> >
> > If however, we have a MAC connected to a backplane, and on the end of
> > the backplane is a traditional PHY, or an SFP cage, we have problems.
> > As your point out, we cannot have two PHYs in a chain for one MAC.
> >
> > But i agree with Russell. We need a general solution of how we deal
> > with PCSs.
> 
> What really worries me is that we may be driving the same hardware
> with two different approaches/drivers for two different applications
> which isn't going to work out very well in the long run.

The same HW can be used in multiple ways here so having different drivers
for these modes is not really an issue, you won't be able to use it both
in backplane and non-backplane mode at the same time.

Besides the (oversimplifying) model used in SW, there is no constraint
to have just one independently manageable entity belonging to the PHY
layer. Nowadays there are complex configurable PCS/PMA units, retimers,
single chip PHYs that can function also in backplane mode, and so on.
All these require a rethinking of the one PHY per interface, tied to a
MDIO bus model we use today. The DPAA 1 already make use of the MDIO bus
infrastructure to manage the PCS devices in the SoC, without an issue
related to the PHYlib one PHY assumption.

One risk I see here is that we may abandon PHYlib before we give it a
chance to adapt to the new complexity of the HW and roll something new
just to do away with the required work in understanding its inner workings.
This could even be fine but it creates a no return point for drivers that
will use a new infrastructure we put in place (i.e. no backporting).

Madalin