-----Original Message-----
From: netdev-owner@vger.kernel.org <redacted> On
Behalf Of Russell King - ARM Linux admin
Sent: Friday, March 27, 2020 7:35 PM
To: Andrew Lunn <andrew@lunn.ch>
Cc: Florinel Iordache <redacted>; davem@davemloft.net;
netdev@vger.kernel.org; f.fainelli@gmail.com; hkallweit1@gmail.com;
devicetree@vger.kernel.org; linux-doc@vger.kernel.org; robh+dt@kernel.org;
mark.rutland@arm.com; kuba@kernel.org; corbet@lwn.net;
shawnguo@kernel.org; Leo Li [off-list ref]; Madalin Bucur (OSS)
[off-list ref]; Ioana Ciornei [off-list ref]; linux-
kernel@vger.kernel.org
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:

quoted

quoted

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