[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AM6PR04MB397677E90EFBD9749D01B061EC970@AM6PR04MB3976.eurprd04.prod.outlook.com>
Date: Mon, 22 Jun 2020 15:08:36 +0000
From: "Madalin Bucur (OSS)" <madalin.bucur@....nxp.com>
To: Andrew Lunn <andrew@...n.ch>,
Florinel Iordache <florinel.iordache@....com>
CC: "davem@...emloft.net" <davem@...emloft.net>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"f.fainelli@...il.com" <f.fainelli@...il.com>,
"hkallweit1@...il.com" <hkallweit1@...il.com>,
"linux@...linux.org.uk" <linux@...linux.org.uk>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
"robh+dt@...nel.org" <robh+dt@...nel.org>,
"mark.rutland@....com" <mark.rutland@....com>,
"kuba@...nel.org" <kuba@...nel.org>,
"corbet@....net" <corbet@....net>,
"shawnguo@...nel.org" <shawnguo@...nel.org>,
Leo Li <leoyang.li@....com>,
"Madalin Bucur (OSS)" <madalin.bucur@....nxp.com>,
Ioana Ciornei <ioana.ciornei@....com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH net-next v3 4/7] net: phy: add backplane kr driver support
> -----Original Message-----
> From: Andrew Lunn <andrew@...n.ch>
> Sent: Monday, June 22, 2020 5:25 PM
> To: Florinel Iordache <florinel.iordache@....com>
> Cc: davem@...emloft.net; netdev@...r.kernel.org; f.fainelli@...il.com;
> hkallweit1@...il.com; linux@...linux.org.uk; devicetree@...r.kernel.org;
> linux-doc@...r.kernel.org; robh+dt@...nel.org; mark.rutland@....com;
> kuba@...nel.org; corbet@....net; shawnguo@...nel.org; Leo Li
> <leoyang.li@....com>; Madalin Bucur (OSS) <madalin.bucur@....nxp.com>;
> Ioana Ciornei <ioana.ciornei@....com>; linux-kernel@...r.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:
> > 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
Powered by blists - more mailing lists