Re: [EXT] Re: [PATCH net-next 3/9] net: phy: add kr phy connection type

[Russell King - ARM Linux admin]

On Sun, Mar 29, 2020 at 08:22:10AM +0000, Florinel Iordache wrote:
> > On Thu, Mar 26, 2020 at 03:51:16PM +0200, Florinel Iordache wrote:
> > > Add support for backplane kr phy connection types currently available
> > > (10gbase-kr, 40gbase-kr4) and the required phylink updates (cover all
> > > the cases for KR modes which are clause 45 compatible to correctly
> > > assign phy_interface and phylink#supported)
> > >
> > > Signed-off-by: Florinel Iordache <florinel.iordache@xxxxxxx>
> > > ---
> > >  drivers/net/phy/phylink.c | 15 ++++++++++++---
> > >  include/linux/phy.h       |  6 +++++-
> > >  2 files changed, 17 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
> > > index fed0c59..db1bb87 100644
> > > --- a/drivers/net/phy/phylink.c
> > > +++ b/drivers/net/phy/phylink.c
> > > @@ -4,6 +4,7 @@
> > >   * technologies such as SFP cages where the PHY is hot-pluggable.
> > >   *
> > >   * Copyright (C) 2015 Russell King
> > > + * Copyright 2020 NXP
> > >   */
> > >  #include <linux/ethtool.h>
> > >  #include <linux/export.h>
> > > @@ -303,7 +304,6 @@ static int phylink_parse_mode(struct phylink *pl, struct
> > fwnode_handle *fwnode)
> > >                       break;
> > >
> > >               case PHY_INTERFACE_MODE_USXGMII:
> > > -             case PHY_INTERFACE_MODE_10GKR:
> > 
> > We might have a backwards compatibility issue here. If i remember correctly,
> > there are some boards out in the wild using PHY_INTERFACE_MODE_10GKR not
> > PHY_INTERFACE_MODE_10GBASER.
> > 
> > See e0f909bc3a242296da9ccff78277f26d4883a79d
> > 
> > Russell, what do you say about this?
> > 
> >          Andrew
> 
> Ethernet interface nomenclature is using the following terminology:
> e.g. 10GBase-KR: data rate (10G),  modulation type (Base = Baseband),
> medium type (K = BacKplane), physical layer encoding scheme
> (R = scRambling/descRambling using 64b/66b encoding that allows for
> Ethernet framing at a rate of 10.3125 Gbit/s)
> So 10GBase-R name provide information only about the data rate and
> the encoding scheme without specifying the interface medium.
> 10GBase-R is a family of many different standards specified for
> several different physical medium for copper and optical fiber like
> for example:
> 	10GBase-SR: Short range (over fiber)
> 	10GBase-LR: Long reach (over fiber)
> 	10GBase-LRM: Long reach multi-mode (over fiber)
> 	10GBase-ER: Extended reach (over fiber)
> 	10GBase-CR: 10G over copper
> 	10GBase-KR: Backplane
> 
> 10GBase-KR represents Ethernet operation over electrical backplanes on
> single lane and uses the same physical layer encoding as 10GBase-LR/ER/SR
> defined in IEEE802.3 Clause 49. 

I'm not sure why NXP folk think that they have to keep explaining this
to us.  You do not.

> So prior to my change, phy_interface_t provided both enumerators which is correct:
> 	PHY_INTERFACE_MODE_10GBASER
> 	PHY_INTERFACE_MODE_10GKR
> Perhaps PHY_INTERFACE_MODE_10GKR was not used before because Backplane
> support was not available and all 10GBase-R family of interfaces should
> be using PHY_INTERFACE_MODE_10GBASER.

What you are missing is that PHY_INTERFACE_MODE_10GKR was introduced
first and used _incorrectly_.  We are currently mid-transition to
correct that mistake.

While we are in transition, PHY_INTERFACE_MODE_10GKR can _not_ be used
correctly, and nothing NXP or anyone else says will change that fact
until the transition has been completed.

In kernel land, we do not intentionally regress platforms, even if we
have made a mistake.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up