-----Original Message-----
From: Florian Fainelli <f.fainelli@gmail.com>
Sent: Friday, June 26, 2020 10:05 PM
To: Florinel Iordache <redacted>; Andrew Lunn
[off-list ref]
Cc: davem@davemloft.net; netdev@vger.kernel.org; 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: [EXT] Re: [PATCH net-next v3 4/7] net: phy: add backplane kr driver
support

Caution: EXT Email

On 6/22/20 7:39 AM, Florinel Iordache wrote:

quoted

quoted

-----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: [EXT] Re: [PATCH net-next v3 4/7] net: phy: add backplane kr
driver support

Caution: EXT Email

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.

quoted

quoted

        Andrew

Hi Andrew,

Yes, you are right: we decided to send only support for DPAA1 using
current approach as a PHY device (as mentioned in cover-letter), until PCS

representation will be fully clarified.

quoted

The entire DPAA2 support was removed for now, together with phylink

changes.

quoted

DPAA1 maintainer (Madalin Bucur) agrees with current representation as a PHY

device for DPAA1.

quoted

So we would like to have some discussions around this approach for DPAA1

only, as it seems suitable for us.

The question is really whether it is suitable for others beyond NXP, the drivers
are certainly organized in such a way that there is little NXP specifics in them so
the intent is clearly there.

We will probably not know, either because vendors have decided to hide all of
this stuff under firmware, or they do not use Linux or they just are not following
what is going on upstream and have no desire to participate.
--
Florian

Hi Florian,
This is correct: backplane support has a modular, extensible, generic architecture
and the modules are completely disconnected
so they can be reused among different configurations setups.
Therefore we have encapsulated the standard backplane functionality in several
generic modules like: Ethernet Backplane Generic Driver, Link Training and
Auto-negotiation including: IEEE 802.3-ap/ba standards, Equalization Algorithms
(that include: Fixed algorithm and BEE - Bit Edge equalization algorithm).
Device specific modules are used to enable QorIQ family of devices.
This architecture is described in detail in Doc file: backplane.rst
Other vendors that want to enable backplane for their devices should
add only their device specific modules (similar with qoriq modules).
These modules basically must describe device specific registers and
make the connection between backplane generic API services and device specific operations.
All generic modules that encapsulate standard backplane functionality can be
reused by other vendors but this is not mandatory.
Other vendors can extend current architecture with new generic modules:
for example other equalization algorithms and standards can be added in the future
if currently existing ones are not desired or considered inappropriate.
There are several other standard algorithms available that can be used for
Signal equalization: they just have to be implemented and integrated here.
Of course we validated this backplane architecture only on NXP platforms (by using QorIQ devices)
but other vendors will be able to use it in the future on their own platforms.
Thank you for feedback,
Florinel.