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

[Florian Fainelli]

On 6/22/20 8:08 AM, Madalin Bucur (OSS) 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: 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:
>>> 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

That argument makes sense.

> - the PHY driver provides the state machine that is required, not using
> this representation backplane would need to add a separate, duplicate
> state machine

Which is entirely permissible according to the PHY library
documentation, not that we have seen many people do it though, even less
so when the PHY driver is providing the 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.

So would not it make sense for the PCS representation to be settled and
then add the backplane driver implementation such that there is no
double work happening for Florinel and for reviewers and the PCS
implementation als factors in the backplane use case and requirements?
-- 
Florian