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