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

[Russell King - ARM Linux admin <linux@armlinux.org.uk>]

On Fri, Jun 26, 2020 at 12:02:05PM -0700, Florian Fainelli wrote:
> On 6/22/20 8:08 AM, Madalin Bucur (OSS) wrote:
> > 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.

It doesn't when you also are subjected to other parts of NXP arguing
that the PCS is tightly bound inside the SoC and therefore should be
effectively a library - as has been discussed in the threads about
the Lynx PCS.

> > - 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.

It seems the PHYlib state machine is getting smaller and smaller
as we move forward; phy_state_machine() is now looking very bare
compared to what it used to look like.  I think it's not that far
off being eliminated.

> > - 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?

Yes, that is my assessment; there's a lot of work going on in different
areas in QoriQ networking, and it seems people are pulling things in
quite diverse directions.

If we're not careful, we're going to end up with the Lynx PCS being
implemented one way, and backplane PCS being implemented completely
differently and preventing any hope of having a backplane PCS
connected to a conventional copper PHY.

I think folk at NXP need to stop, stand back, and look at the bigger
picture about how they want to integrate all these individual,
independent strands of development into the kernel, and come up with
a common approach that also satisfies the mainline kernel, rather
than having individual discussions with mainline kernel maintainers
on public lists.  What I'm saying is, it isn't our job to co-ordinate
between the different parts of NXP - that's fairly and squarely
NXP's problem to sort out themselves.

So, I think, further progress in public on backplane support needs to
wait until we have the general situation for PCS resolved.

Makes sense?

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!