-----Original Message-----
From: Andrew Lunn <andrew@lunn.ch>
Sent: Monday, June 22, 2020 5:25 PM
To: Florinel Iordache <redacted>
Cc: davem@davemloft.net; netdev@vger.kernel.org; f.fainelli@gmail.com;
hkallweit1@gmail.com; linux@armlinux.org.uk; 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: [PATCH net-next v3 4/7] net: phy: add backplane kr driver
support

On Mon, Jun 22, 2020 at 04:35:21PM +0300, Florinel Iordache wrote:

quoted

Add support for backplane kr generic driver including link training
(ieee802.3ap/ba) and fixed equalization algorithm

Hi Florinel

This is still a PHY device. I don't remember any discussions which
resolved the issues of if at the end of the backplane there is another
PHY.

It makes little sense to repost this code until we have this problem
discussed and a way forward decided on. It fits into the discussion
Russell and Ioana are having about representing PCS drivers. Please
contribute to that.

	Andrew

Hi Andrew, the reasons behind this selection:

- the PCS that is controlled by the backplane driver belongs to the PHY
layer so the representation as a PHY device is legitimate
- the PHY driver provides the state machine that is required, not using
this representation backplane would need to add a separate, duplicate
state machine
- the limitation, that only one PHY layer entity can be managed by the
PHYLib, is a known limitation that always existed, is not introduced by
the backplane support; the unsupported scenario with a backplane connection
to a PHY entity that needs to be managed relates to that limitation and
a solution for it should not be added through the backplane support
- afaik, Russell and Ioana are discussing the PCS representation in the
context of PHYLink, this submission is using PHYLib. If we are to discuss
about the PCS representation, it's the problem of the simplistic "one device
in the PHY layer" issue that needs to be addressed to have a proper PCS
representation at all times.

Madalin