RE: [EXT] Re: [PATCH net-next v3 4/7] net: phy: add backplane kr driver support

[Florinel Iordache]

> -----Original Message-----
> From: Florian Fainelli <f.fainelli@xxxxxxxxx>
> Sent: Friday, June 26, 2020 10:05 PM
> To: Florinel Iordache <florinel.iordache@xxxxxxx>; Andrew Lunn
> <andrew@xxxxxxx>
> Cc: davem@xxxxxxxxxxxxx; netdev@xxxxxxxxxxxxxxx; hkallweit1@xxxxxxxxx;
> linux@xxxxxxxxxxxxxxx; 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 v3 4/7] net: phy: add backplane kr driver
> support
> 
> Caution: EXT Email
> 
> On 6/22/20 7:39 AM, Florinel Iordache wrote:
> >> -----Original Message-----
> >> From: Andrew Lunn <andrew@xxxxxxx>
> >> Sent: Monday, June 22, 2020 5:25 PM
> >> To: Florinel Iordache <florinel.iordache@xxxxxxx>
> >> Cc: davem@xxxxxxxxxxxxx; netdev@xxxxxxxxxxxxxxx;
> >> f.fainelli@xxxxxxxxx; hkallweit1@xxxxxxxxx; linux@xxxxxxxxxxxxxxx;
> >> 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: [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:
> >>> 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,
> >
> > 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.
> > The entire DPAA2 support was removed for now, together with phylink
> changes.
> > DPAA1 maintainer (Madalin Bucur) agrees with current representation as a PHY
> device for DPAA1.
> > 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.