From: Andrew Lunn <andrew@lunn.ch> Date: 2020-06-22 14:24:44
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
-----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.
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.
Regards,
Florinel.
-----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: 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:
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.
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
- the PHY driver provides the state machine that is required, not using
this representation backplane would need to add a separate, duplicate
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.
Madalin
-----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: 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:
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.
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
-----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.
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
From: Russell King - ARM Linux admin <linux@armlinux.org.uk> Date: 2020-06-29 18:47:55
On Fri, Jun 26, 2020 at 12:02:05PM -0700, Florian Fainelli wrote:
On 6/22/20 8:08 AM, Madalin Bucur (OSS) wrote:
quoted
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.
quoted
- 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.
quoted
- 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!
-----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.