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

[Florian Fainelli <f.fainelli@gmail.com>]

On 6/22/20 7:39 AM, Florinel Iordache wrote:
>> -----Original Message-----
>> From: Andrew Lunn <andrew@lunn.ch>
>> Sent: Monday, June 22, 2020 5:25 PM
>> To: Florinel Iordache <florinel.iordache@nxp.com>
>> 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
>> <leoyang.li@nxp.com>; Madalin Bucur (OSS) <madalin.bucur@oss.nxp.com>;
>> Ioana Ciornei <ioana.ciornei@nxp.com>; 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:
>>> 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