| Message ID | 1585230682-24417-4-git-send-email-florinel.iordache@nxp.com |
|---|---|
| State | Changes Requested |
| Delegated to: | David Miller |
| Headers | show |
| Series | net: ethernet backplane support | expand |
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@nxp.com> > --- > 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
On 3/26/2020 6:51 AM, 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@nxp.com> > --- > drivers/net/phy/phylink.c | 15 ++++++++++++--- > include/linux/phy.h | 6 +++++- > 2 files changed, 17 insertions(+), 4 deletions(-) Please remember to update Documentation/networking/phy.rst, and Documentation/ABI/testing/sysfs-class-net-phydev with these new PHY interface values.
On Fri, Mar 27, 2020 at 01:15:15AM +0100, Andrew Lunn 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@nxp.com> > > --- > > 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? Yes, and that's a point that I made when I introduced 10GBASER to correct that mistake. It is way too soon to change this; it will definitely cause regressions: $ grep 10gbase-kr arch/*/boot/dts -r arch/arm64/boot/dts/marvell/cn9131-db.dts: phy-mode = "10gbase-kr"; arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts: phy-mode = "10gbase-kr"; arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts: phy-mode = "10gbase-kr"; arch/arm64/boot/dts/marvell/armada-7040-db.dts: phy-mode = "10gbase-kr"; arch/arm64/boot/dts/marvell/armada-8040-mcbin-singleshot.dts: phy-mode = "10gbase-kr"; arch/arm64/boot/dts/marvell/armada-8040-mcbin-singleshot.dts: phy-mode = "10gbase-kr"; arch/arm64/boot/dts/marvell/armada-8040-clearfog-gt-8k.dts: phy-mode = "10gbase-kr"; arch/arm64/boot/dts/marvell/armada-8040-db.dts: phy-mode = "10gbase-kr"; arch/arm64/boot/dts/marvell/armada-8040-db.dts: phy-mode = "10gbase-kr"; arch/arm64/boot/dts/marvell/cn9132-db.dts: phy-mode = "10gbase-kr"; arch/arm64/boot/dts/marvell/cn9130-db.dts: phy-mode = "10gbase-kr"; So any change to the existing PHY_INTERFACE_MODE_10GKR will likely break all these platforms.
> -----Original Message----- > From: netdev-owner@vger.kernel.org <netdev-owner@vger.kernel.org> On > Behalf Of Russell King - ARM Linux admin > Sent: Friday, March 27, 2020 2:02 PM > To: Andrew Lunn <andrew@lunn.ch> > Cc: Florinel Iordache <florinel.iordache@nxp.com>; davem@davemloft.net; > netdev@vger.kernel.org; f.fainelli@gmail.com; hkallweit1@gmail.com; > 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 <leoyang.li@nxp.com>; Madalin Bucur (OSS) > <madalin.bucur@oss.nxp.com>; Ioana Ciornei <ioana.ciornei@nxp.com>; linux- > kernel@vger.kernel.org > Subject: Re: [PATCH net-next 3/9] net: phy: add kr phy connection type > > On Fri, Mar 27, 2020 at 01:15:15AM +0100, Andrew Lunn 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@nxp.com> > > > --- > > > 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? > > Yes, and that's a point that I made when I introduced 10GBASER to > correct that mistake. It is way too soon to change this; it will > definitely cause regressions: > > $ grep 10gbase-kr arch/*/boot/dts -r > arch/arm64/boot/dts/marvell/cn9131-db.dts: phy-mode = "10gbase-kr"; > arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts: phy-mode = > "10gbase-kr"; > arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts: phy-mode = > "10gbase-kr"; > arch/arm64/boot/dts/marvell/armada-7040-db.dts: phy-mode = "10gbase- > kr"; > arch/arm64/boot/dts/marvell/armada-8040-mcbin-singleshot.dts: phy-mode = > "10gbase-kr"; > arch/arm64/boot/dts/marvell/armada-8040-mcbin-singleshot.dts: phy-mode = > "10gbase-kr"; > arch/arm64/boot/dts/marvell/armada-8040-clearfog-gt-8k.dts: phy-mode = > "10gbase-kr"; > arch/arm64/boot/dts/marvell/armada-8040-db.dts: phy-mode = "10gbase-kr"; > arch/arm64/boot/dts/marvell/armada-8040-db.dts: phy-mode = "10gbase-kr"; > arch/arm64/boot/dts/marvell/cn9132-db.dts: phy-mode = "10gbase-kr"; > arch/arm64/boot/dts/marvell/cn9130-db.dts: phy-mode = "10gbase-kr"; > > So any change to the existing PHY_INTERFACE_MODE_10GKR will likely > break all these platforms. > > -- > 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 Hi Russell, I hoped a fix for those would be in by now, it's not useful to leave them like that. We have a similar situation, where all boards using XFI interfaces contain phy-connection-type="xgmii" for a long time now but that did not stop anyone from adding a warning in the Aquantia driver: + WARN(phydev->interface == PHY_INTERFACE_MODE_XGMII, + "Your devicetree is out of date, please update it. The AQR107 family doesn't support XGMII, maybe you mean USXGMII.\n"); + Maybe we need a warning added here too, until the proper phy-mode is used for these boards, to allow for a transition period. Madalin
On Fri, Mar 27, 2020 at 12:12:37PM +0000, Madalin Bucur (OSS) wrote: > > -----Original Message----- > > From: netdev-owner@vger.kernel.org <netdev-owner@vger.kernel.org> On > > Behalf Of Russell King - ARM Linux admin > > Sent: Friday, March 27, 2020 2:02 PM > > To: Andrew Lunn <andrew@lunn.ch> > > Cc: Florinel Iordache <florinel.iordache@nxp.com>; davem@davemloft.net; > > netdev@vger.kernel.org; f.fainelli@gmail.com; hkallweit1@gmail.com; > > 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 <leoyang.li@nxp.com>; Madalin Bucur (OSS) > > <madalin.bucur@oss.nxp.com>; Ioana Ciornei <ioana.ciornei@nxp.com>; linux- > > kernel@vger.kernel.org > > Subject: Re: [PATCH net-next 3/9] net: phy: add kr phy connection type > > > > On Fri, Mar 27, 2020 at 01:15:15AM +0100, Andrew Lunn 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@nxp.com> > > > > --- > > > > 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? > > > > Yes, and that's a point that I made when I introduced 10GBASER to > > correct that mistake. It is way too soon to change this; it will > > definitely cause regressions: > > > > $ grep 10gbase-kr arch/*/boot/dts -r > > arch/arm64/boot/dts/marvell/cn9131-db.dts: phy-mode = "10gbase-kr"; > > arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts: phy-mode = > > "10gbase-kr"; > > arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts: phy-mode = > > "10gbase-kr"; > > arch/arm64/boot/dts/marvell/armada-7040-db.dts: phy-mode = "10gbase- > > kr"; > > arch/arm64/boot/dts/marvell/armada-8040-mcbin-singleshot.dts: phy-mode = > > "10gbase-kr"; > > arch/arm64/boot/dts/marvell/armada-8040-mcbin-singleshot.dts: phy-mode = > > "10gbase-kr"; > > arch/arm64/boot/dts/marvell/armada-8040-clearfog-gt-8k.dts: phy-mode = > > "10gbase-kr"; > > arch/arm64/boot/dts/marvell/armada-8040-db.dts: phy-mode = "10gbase-kr"; > > arch/arm64/boot/dts/marvell/armada-8040-db.dts: phy-mode = "10gbase-kr"; > > arch/arm64/boot/dts/marvell/cn9132-db.dts: phy-mode = "10gbase-kr"; > > arch/arm64/boot/dts/marvell/cn9130-db.dts: phy-mode = "10gbase-kr"; > > > > So any change to the existing PHY_INTERFACE_MODE_10GKR will likely > > break all these platforms. > > Hi Russell, > > I hoped a fix for those would be in by now, it's not useful to leave them like > that. I haven't had the time to address the ones I know about, sorry. However, there are some platforms in that list which I've no knowledge of, which I therefore can't change. > We have a similar situation, where all boards using XFI interfaces contain > phy-connection-type="xgmii" for a long time now but that did not stop anyone from > adding a warning in the Aquantia driver: > > + WARN(phydev->interface == PHY_INTERFACE_MODE_XGMII, > + "Your devicetree is out of date, please update it. The AQR107 family doesn't support XGMII, maybe you mean USXGMII.\n"); > + > > Maybe we need a warning added here too, until the proper phy-mode is used for > these boards, to allow for a transition period. Adding a warning can only be done once the current users have been updated, otherwise it's technically introducing a regression. Plus some users may actually be correct. I never did get to the bottom of that, because that required discussion and no one seems willing to discuss it.
> 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@nxp.com> > > --- > > 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. 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. In case PHY_INTERFACE_MODE_10GKR was used before, this is probably incorrect and should be changed for those boards to use the correct phy connection type: PHY_INTERFACE_MODE_10GBASER. Moreover now I also introduced a new phy connection type to cover also: 40GBase-KR4 which is 40G Backplane over 4-lanes: PHY_INTERFACE_MODE_40GKR4 Prior to adding backplane support, 10GKR case was handled the same as 10GBASER in phylink_parse_mode. But now because we are adding support for backplane modes, all backplane phy connection types (like: 10GKR, 40GKR4) must be treated separately to correctly setup the supported phylink. Florin.
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@nxp.com> > > > --- > > > 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.
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: case PHY_INTERFACE_MODE_10GBASER: phylink_set(pl->supported, 10baseT_Half); phylink_set(pl->supported, 10baseT_Full); @@ -317,7 +317,6 @@ static int phylink_parse_mode(struct phylink *pl, struct fwnode_handle *fwnode) phylink_set(pl->supported, 2500baseX_Full); phylink_set(pl->supported, 5000baseT_Full); phylink_set(pl->supported, 10000baseT_Full); - phylink_set(pl->supported, 10000baseKR_Full); phylink_set(pl->supported, 10000baseKX4_Full); phylink_set(pl->supported, 10000baseCR_Full); phylink_set(pl->supported, 10000baseSR_Full); @@ -326,6 +325,14 @@ static int phylink_parse_mode(struct phylink *pl, struct fwnode_handle *fwnode) phylink_set(pl->supported, 10000baseER_Full); break; + case PHY_INTERFACE_MODE_10GKR: + phylink_set(pl->supported, 10000baseKR_Full); + break; + + case PHY_INTERFACE_MODE_40GKR4: + phylink_set(pl->supported, 40000baseKR4_Full); + break; + case PHY_INTERFACE_MODE_XLGMII: phylink_set(pl->supported, 25000baseCR_Full); phylink_set(pl->supported, 25000baseKR_Full); @@ -823,7 +830,9 @@ static int phylink_bringup_phy(struct phylink *pl, struct phy_device *phy, if (phy->is_c45 && interface != PHY_INTERFACE_MODE_RXAUI && interface != PHY_INTERFACE_MODE_XAUI && - interface != PHY_INTERFACE_MODE_USXGMII) + interface != PHY_INTERFACE_MODE_USXGMII && + interface != PHY_INTERFACE_MODE_10GKR && + interface != PHY_INTERFACE_MODE_40GKR4) config.interface = PHY_INTERFACE_MODE_NA; else config.interface = interface; diff --git a/include/linux/phy.h b/include/linux/phy.h index 2432ca4..d7cca4b 100644 --- a/include/linux/phy.h +++ b/include/linux/phy.h @@ -6,6 +6,7 @@ * Author: Andy Fleming * * Copyright (c) 2004 Freescale Semiconductor, Inc. + * Copyright 2020 NXP */ #ifndef __PHY_H @@ -107,8 +108,9 @@ /* 10GBASE-R, XFI, SFI - single lane 10G Serdes */ PHY_INTERFACE_MODE_10GBASER, PHY_INTERFACE_MODE_USXGMII, - /* 10GBASE-KR - with Clause 73 AN */ + /* Backplane KR */ PHY_INTERFACE_MODE_10GKR, + PHY_INTERFACE_MODE_40GKR4, PHY_INTERFACE_MODE_MAX, } phy_interface_t; @@ -190,6 +192,8 @@ static inline const char *phy_modes(phy_interface_t interface) return "usxgmii"; case PHY_INTERFACE_MODE_10GKR: return "10gbase-kr"; + case PHY_INTERFACE_MODE_40GKR4: + return "40gbase-kr4"; default: return "unknown"; }
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@nxp.com> --- drivers/net/phy/phylink.c | 15 ++++++++++++--- include/linux/phy.h | 6 +++++- 2 files changed, 17 insertions(+), 4 deletions(-)