| Message ID | 20220725153730.2604096-3-sean.anderson@seco.com (mailing list archive) |
|---|---|
| State | Changes Requested |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | net: phy: Add support for rate adaptation | expand |
On Mon, Jul 25, 2022 at 11:37:20AM -0400, Sean Anderson wrote: > Add 1000BASE-KX interface mode. This 1G backplane ethernet as described in > clause 70. Clause 73 autonegotiation is mandatory, and only full duplex > operation is supported. > > Signed-off-by: Sean Anderson <sean.anderson@seco.com> > --- What does 1000BASE-KX have to do with anything?
On 8/18/22 12:53 PM, Vladimir Oltean wrote: > On Mon, Jul 25, 2022 at 11:37:20AM -0400, Sean Anderson wrote: >> Add 1000BASE-KX interface mode. This 1G backplane ethernet as described in >> clause 70. Clause 73 autonegotiation is mandatory, and only full duplex >> operation is supported. >> >> Signed-off-by: Sean Anderson <sean.anderson@seco.com> >> --- > > What does 1000BASE-KX have to do with anything? > It doesn't, really. This should have been part of [1], but it looks like I put it in the wrong series. --Sean [1] https://lore.kernel.org/linux-phy/20220804220602.477589-1-sean.anderson@seco.com/
On 8/18/22 12:57 PM, Sean Anderson wrote: > > > On 8/18/22 12:53 PM, Vladimir Oltean wrote: >> On Mon, Jul 25, 2022 at 11:37:20AM -0400, Sean Anderson wrote: >>> Add 1000BASE-KX interface mode. This 1G backplane ethernet as described in >>> clause 70. Clause 73 autonegotiation is mandatory, and only full duplex >>> operation is supported. >>> >>> Signed-off-by: Sean Anderson <sean.anderson@seco.com> >>> --- >> >> What does 1000BASE-KX have to do with anything? >> > > It doesn't, really. This should have been part of [1], but it looks like I > put it in the wrong series. > > --Sean > > [1] https://lore.kernel.org/linux-phy/20220804220602.477589-1-sean.anderson@seco.com/ > Well, I suppose the real reason is that this will cause a merge conflict (or lack of one), since this series introduces phylink_interface_max_speed in patch 7, which is supposed to contain all the phy modes. So depending on what gets merged first, the other series will have to be modified and resent. To be honest, I had expected that trivial patches like that would have been applied and merged already. --Sean
On Thu, Aug 18, 2022 at 01:03:54PM -0400, Sean Anderson wrote: > Well, I suppose the real reason is that this will cause a merge conflict > (or lack of one), since this series introduces phylink_interface_max_speed > in patch 7, which is supposed to contain all the phy modes. So depending on > what gets merged first, the other series will have to be modified and resent. > > To be honest, I had expected that trivial patches like that would have been > applied and merged already. There's nothing trivial about this patch. 1000Base-KX is not a phy-mode in exactly the same way that 1000Base-T isn't, either. If you want to bring PHY_INTERFACE_MODE_10GKR as a "yes, but" counterexample, it was later clarified that 10gbase-r was what was actually meant in that case, and we keep 10gbase-kr as phy-mode only for compatibility with some device trees. I'd suggest resolving the merge conflict without 1000Base-KX and splitting off a separate discussion about this topic. Otherwise it will unnecessarily detract from PAUSE-based rate adaptation.
On 8/18/22 1:12 PM, Vladimir Oltean wrote: > On Thu, Aug 18, 2022 at 01:03:54PM -0400, Sean Anderson wrote: >> Well, I suppose the real reason is that this will cause a merge conflict >> (or lack of one), since this series introduces phylink_interface_max_speed >> in patch 7, which is supposed to contain all the phy modes. So depending on >> what gets merged first, the other series will have to be modified and resent. >> >> To be honest, I had expected that trivial patches like that would have been >> applied and merged already. > > There's nothing trivial about this patch. Perhaps "limited in scope and mostly independent" is better, then. > 1000Base-KX is not a phy-mode > in exactly the same way that 1000Base-T isn't, either. It has different AN from 1000BASE-X (c73 vs c37), and doesn't support half duplex. This is something the serdes and PCS have to care about. Unfortunately, we don't have a separate PCS_INTERFACE_MODE so these things become PHY_INTERFACE_MODEs. > If you want to > bring PHY_INTERFACE_MODE_10GKR as a "yes, but" counterexample, it was > later clarified that 10gbase-r was what was actually meant in that case, > and we keep 10gbase-kr as phy-mode only for compatibility with some > device trees. That's not what's documented: > ``PHY_INTERFACE_MODE_10GBASER`` > This is the IEEE 802.3 Clause 49 defined 10GBASE-R protocol used with > various different mediums. Please refer to the IEEE standard for a > definition of this. > > Note: 10GBASE-R is just one protocol that can be used with XFI and SFI. > XFI and SFI permit multiple protocols over a single SERDES lane, and > also defines the electrical characteristics of the signals with a host > compliance board plugged into the host XFP/SFP connector. Therefore, > XFI and SFI are not PHY interface types in their own right. > > ``PHY_INTERFACE_MODE_10GKR`` > This is the IEEE 802.3 Clause 49 defined 10GBASE-R with Clause 73 > autonegotiation. Please refer to the IEEE standard for further > information. > > Note: due to legacy usage, some 10GBASE-R usage incorrectly makes > use of this definition. so indeed you get a new phy interface mode when you add c73 AN. The clarification only applies to *incorrect* usage. > I'd suggest resolving the merge conflict without 1000Base-KX and > splitting off a separate discussion about this topic. Otherwise it will > unnecessarily detract from PAUSE-based rate adaptation. Well, no one is using it yet, so hopefully it will not be a problem... --Sean
On Thu, Aug 18, 2022 at 01:28:19PM -0400, Sean Anderson wrote: > That's not what's documented: > > > ``PHY_INTERFACE_MODE_10GBASER`` > > This is the IEEE 802.3 Clause 49 defined 10GBASE-R protocol used with > > various different mediums. Please refer to the IEEE standard for a > > definition of this. > > > > Note: 10GBASE-R is just one protocol that can be used with XFI and SFI. > > XFI and SFI permit multiple protocols over a single SERDES lane, and > > also defines the electrical characteristics of the signals with a host > > compliance board plugged into the host XFP/SFP connector. Therefore, > > XFI and SFI are not PHY interface types in their own right. > > > > ``PHY_INTERFACE_MODE_10GKR`` > > This is the IEEE 802.3 Clause 49 defined 10GBASE-R with Clause 73 > > autonegotiation. Please refer to the IEEE standard for further > > information. > > > > Note: due to legacy usage, some 10GBASE-R usage incorrectly makes > > use of this definition. > > so indeed you get a new phy interface mode when you add c73 AN. The > clarification only applies to *incorrect* usage. I challenge you to the following thought experiment. Open clause 73 from IEEE 802.3, and see what is actually exchanged through auto-negotiation. You'll discover that the *use* of the 10GBase-KR operating mode is *established* through clause 73 AN (the Technology Ability field). So what sense does it make to define 10GBase-KR as "10Base-R with clause 73 AN" as the document you've quoted does? None whatsoever. The K in KR stands for bacKplane, and typical of this type of PMD are the signaling and link training procedures described in the previous clause, 72. Clause 73 AN is not something that is a property of 10GBase-KR, but something that exists outside of it. So if clause 73 *establishes* the use of 10GBase-KR (or 1000Base-KX or others) through autonegotiation, then what sense does it have to put phy-mode = "1000base-kx" in the device tree? Does it mean "use C73 AN", or "don't use it, I already know what operating mode I want to use"? If it means "use C73 AN", then what advertisement do you use for the Technology Ability field? There's a priority resolution function for C73, just like there is one for C28/C40 for the twisted pair medium (aka that thing that allows you to fall back to the highest supported common link speed). So why would you populate just one bit in Technology Ability based on DT, if you can potentially support multiple operating modes? And why would you even create your advertisement based on the device tree, for that matter? Twisted pair PHYs don't do this.
On 8/18/22 3:51 PM, Vladimir Oltean wrote: > On Thu, Aug 18, 2022 at 01:28:19PM -0400, Sean Anderson wrote: >> That's not what's documented: >> >> > ``PHY_INTERFACE_MODE_10GBASER`` >> > This is the IEEE 802.3 Clause 49 defined 10GBASE-R protocol used with >> > various different mediums. Please refer to the IEEE standard for a >> > definition of this. >> > >> > Note: 10GBASE-R is just one protocol that can be used with XFI and SFI. >> > XFI and SFI permit multiple protocols over a single SERDES lane, and >> > also defines the electrical characteristics of the signals with a host >> > compliance board plugged into the host XFP/SFP connector. Therefore, >> > XFI and SFI are not PHY interface types in their own right. >> > >> > ``PHY_INTERFACE_MODE_10GKR`` >> > This is the IEEE 802.3 Clause 49 defined 10GBASE-R with Clause 73 >> > autonegotiation. Please refer to the IEEE standard for further >> > information. >> > >> > Note: due to legacy usage, some 10GBASE-R usage incorrectly makes >> > use of this definition. >> >> so indeed you get a new phy interface mode when you add c73 AN. The >> clarification only applies to *incorrect* usage. > > I challenge you to the following thought experiment. Open clause 73 from > IEEE 802.3, and see what is actually exchanged through auto-negotiation. > You'll discover that the *use* of the 10GBase-KR operating mode is > *established* through clause 73 AN (the Technology Ability field). > > So what sense does it make to define 10GBase-KR as "10Base-R with clause 73 AN" > as the document you've quoted does?None whatsoever. The K in KR stands > for bacKplane, and typical of this type of PMD are the signaling and > link training procedures described in the previous clause, 72. > Clause 73 AN is not something that is a property of 10GBase-KR, but > something that exists outside of it. You should send a patch; this document is Documentation/networking/phy.rst > So if clause 73 *establishes* the use of 10GBase-KR (or 1000Base-KX or > others) through autonegotiation, then what sense does it have to put > phy-mode = "1000base-kx" in the device tree? Does it mean "use C73 AN", > or "don't use it, I already know what operating mode I want to use"? > > If it means "use C73 AN", then what advertisement do you use for the > Technology Ability field? There's a priority resolution function for > C73, just like there is one for C28/C40 for the twisted pair medium (aka > that thing that allows you to fall back to the highest supported common > link speed). So why would you populate just one bit in Technology > Ability based on DT, if you can potentially support multiple operating > modes? And why would you even create your advertisement based on the > device tree, for that matter? Twisted pair PHYs don't do this. The problem is that our current model looks something like 1. MAC <-- A --> phy (ethernet) --> B <-- far end 2. MAC <-> "PCS" <-> phy (serdes) --> C <-- phy (ethernet) --> B <-- far end 3. --> C <-- transciever --> B <-- far end 4. --> D <-- far end Where 1 is the traditional MAC+phy architecture, 2 is a MAC connected to a phy over a serial link, 3 is a MAC connected to an optical transcievber, and 4 is a backplane connection. A is the phy interface mode, and B is the ethtool link mode. C is also the "phy interface mode", except that sometimes it is highly-dependent on the link mode (e.g. 1000BASE-X) and sometimes it is not (SGMII). The problem is case 4. Here, there isn't really a phy interface mode; just a link mode. Consider the serdes driver. It has to know how to configure itself. Sometimes this will be the phy mode (cases 2 and 3), and sometimes it will be the link mode (case 4). In particular, for a link mode like 1000BASE-SX, it should be configured for 1000BASE-X. But for 1000BASE-KX, it has to be configured for 1000BASE-KX. I suppose the right thing to do here is rework the phy subsystem to use link modes and not phy modes for phy_mode_ext, since it seems like there is a 1000BASE-X link mode. But what should be passed to mac_prepare and mac_select_pcs? As another example, consider the AQR113C. It supports the following (abbreviated) interfaces on the MAC side: - 10GBASE-KR - 1000BASE-KX - 10GBASE-R - 1000BASE-X - USXGMII - SGMII This example of what phy-mode = "1000base-kx" would imply. I would expect that selecting -KX over -X would change the electrical settings to comply with clause 70 (instead of the SFP spec). --Sean
Hi Vladimir, On 8/18/22 4:40 PM, Sean Anderson wrote: > On 8/18/22 3:51 PM, Vladimir Oltean wrote: >> On Thu, Aug 18, 2022 at 01:28:19PM -0400, Sean Anderson wrote: >>> That's not what's documented: >>> >>> > ``PHY_INTERFACE_MODE_10GBASER`` >>> > This is the IEEE 802.3 Clause 49 defined 10GBASE-R protocol used with >>> > various different mediums. Please refer to the IEEE standard for a >>> > definition of this. >>> > >>> > Note: 10GBASE-R is just one protocol that can be used with XFI and SFI. >>> > XFI and SFI permit multiple protocols over a single SERDES lane, and >>> > also defines the electrical characteristics of the signals with a host >>> > compliance board plugged into the host XFP/SFP connector. Therefore, >>> > XFI and SFI are not PHY interface types in their own right. >>> > >>> > ``PHY_INTERFACE_MODE_10GKR`` >>> > This is the IEEE 802.3 Clause 49 defined 10GBASE-R with Clause 73 >>> > autonegotiation. Please refer to the IEEE standard for further >>> > information. >>> > >>> > Note: due to legacy usage, some 10GBASE-R usage incorrectly makes >>> > use of this definition. >>> >>> so indeed you get a new phy interface mode when you add c73 AN. The >>> clarification only applies to *incorrect* usage. >> >> I challenge you to the following thought experiment. Open clause 73 from >> IEEE 802.3, and see what is actually exchanged through auto-negotiation. >> You'll discover that the *use* of the 10GBase-KR operating mode is >> *established* through clause 73 AN (the Technology Ability field). >> >> So what sense does it make to define 10GBase-KR as "10Base-R with clause 73 AN" >> as the document you've quoted does?None whatsoever. The K in KR stands >> for bacKplane, and typical of this type of PMD are the signaling and >> link training procedures described in the previous clause, 72. >> Clause 73 AN is not something that is a property of 10GBase-KR, but >> something that exists outside of it. > > You should send a patch; this document is Documentation/networking/phy.rst > >> So if clause 73 *establishes* the use of 10GBase-KR (or 1000Base-KX or >> others) through autonegotiation, then what sense does it have to put >> phy-mode = "1000base-kx" in the device tree? Does it mean "use C73 AN", >> or "don't use it, I already know what operating mode I want to use"? >> >> If it means "use C73 AN", then what advertisement do you use for the >> Technology Ability field? There's a priority resolution function for >> C73, just like there is one for C28/C40 for the twisted pair medium (aka >> that thing that allows you to fall back to the highest supported common >> link speed). So why would you populate just one bit in Technology >> Ability based on DT, if you can potentially support multiple operating >> modes? And why would you even create your advertisement based on the >> device tree, for that matter? Twisted pair PHYs don't do this. > > The problem is that our current model looks something like > > 1. MAC <-- A --> phy (ethernet) --> B <-- far end > 2. MAC <-> "PCS" <-> phy (serdes) --> C <-- phy (ethernet) --> B <-- far end > 3. --> C <-- transciever --> B <-- far end > 4. --> D <-- far end > > Where 1 is the traditional MAC+phy architecture, 2 is a MAC connected to > a phy over a serial link, 3 is a MAC connected to an optical > transcievber, and 4 is a backplane connection. A is the phy interface > mode, and B is the ethtool link mode. C is also the "phy interface > mode", except that sometimes it is highly-dependent on the link mode > (e.g. 1000BASE-X) and sometimes it is not (SGMII). The problem is case > 4. Here, there isn't really a phy interface mode; just a link mode. > > Consider the serdes driver. It has to know how to configure itself. > Sometimes this will be the phy mode (cases 2 and 3), and sometimes it > will be the link mode (case 4). In particular, for a link mode like > 1000BASE-SX, it should be configured for 1000BASE-X. But for > 1000BASE-KX, it has to be configured for 1000BASE-KX. I suppose the > right thing to do here is rework the phy subsystem to use link modes and > not phy modes for phy_mode_ext, since it seems like there is a > 1000BASE-X link mode. But what should be passed to mac_prepare and > mac_select_pcs? > > As another example, consider the AQR113C. It supports the following > (abbreviated) interfaces on the MAC side: > > - 10GBASE-KR > - 1000BASE-KX > - 10GBASE-R > - 1000BASE-X > - USXGMII > - SGMII > > This example of what phy-mode = "1000base-kx" would imply. I would > expect that selecting -KX over -X would change the electrical settings > to comply with clause 70 (instead of the SFP spec). Do you have any comments on the above? --Sean
On Thu, Aug 25, 2022 at 06:50:23PM -0400, Sean Anderson wrote: > > The problem is that our current model looks something like > > > > 1. MAC <-- A --> phy (ethernet) --> B <-- far end > > 2. MAC <-> "PCS" <-> phy (serdes) --> C <-- phy (ethernet) --> B <-- far end > > 3. --> C <-- transciever --> B <-- far end > > 4. --> D <-- far end > > > > Where 1 is the traditional MAC+phy architecture, 2 is a MAC connected to > > a phy over a serial link, 3 is a MAC connected to an optical > > transcievber, and 4 is a backplane connection. A is the phy interface > > mode, and B is the ethtool link mode. C is also the "phy interface > > mode", except that sometimes it is highly-dependent on the link mode > > (e.g. 1000BASE-X) and sometimes it is not (SGMII). The problem is case > > 4. Here, there isn't really a phy interface mode; just a link mode. > > > > Consider the serdes driver. It has to know how to configure itself. > > Sometimes this will be the phy mode (cases 2 and 3), and sometimes it > > will be the link mode (case 4). In particular, for a link mode like > > 1000BASE-SX, it should be configured for 1000BASE-X. But for > > 1000BASE-KX, it has to be configured for 1000BASE-KX. I suppose the > > right thing to do here is rework the phy subsystem to use link modes and > > not phy modes for phy_mode_ext, since it seems like there is a > > 1000BASE-X link mode. But what should be passed to mac_prepare and > > mac_select_pcs? > > > > As another example, consider the AQR113C. It supports the following > > (abbreviated) interfaces on the MAC side: > > > > - 10GBASE-KR > > - 1000BASE-KX > > - 10GBASE-R > > - 1000BASE-X > > - USXGMII > > - SGMII > > > > This example of what phy-mode = "1000base-kx" would imply. I would > > expect that selecting -KX over -X would change the electrical settings > > to comply with clause 70 (instead of the SFP spec). > > Do you have any comments on the above? What comments do you expect? My message was just don't get sidetracked by trying to tackle problems you don't need to solve, thinking they're just there, along the way. "The problem" of wanting to describe an electrical using phy-mode was discussed before, with debatable degrees of success and the following synopsis: | phy_interface_t describes the protocol *only*, it doesn't describe | the electrical characteristics of the interface. So, if we exclude | the electrical characteristics of SFI, we're back to 10GBASE-R, | 10GBASE-W, 10GFC or 10GBASE-R with FEC. That's what phy_interface_t | is, not SFI. | | So, I propose that we add 10GBASE-R to the list and *not* SFI. https://lore.kernel.org/netdev/20191223105719.GM25745@shell.armlinux.org.uk/ I don't have access to 802.3 right now to double check, but I think this is a similar case here - between 1000Base-SX and 1000Base-KX, only the PMA/PMD is different, otherwise they are still both 1000Base-X in terms of protocol/coding. As for the second "example". I had opened my copy of the AQR113C manual and IIRC it listed 10GBASE-KR in the system interfaces, but I don't recall seeing 1000Base-KX. And even for 10GBASE-KR, there weren't a lot of details, like what is configurable about it, is there C73 available etc. Not extremely clear what that is about, tbh. Something that has 10GBase-KR on system side and 10GBase-T on media side sounds like a media converter to me. Not sure how we model those in phylib (I think the answer is we don't).
On 8/25/22 7:45 PM, Vladimir Oltean wrote: > On Thu, Aug 25, 2022 at 06:50:23PM -0400, Sean Anderson wrote: >> > The problem is that our current model looks something like >> > >> > 1. MAC <-- A --> phy (ethernet) --> B <-- far end >> > 2. MAC <-> "PCS" <-> phy (serdes) --> C <-- phy (ethernet) --> B <-- far end >> > 3. --> C <-- transciever --> B <-- far end >> > 4. --> D <-- far end >> > >> > Where 1 is the traditional MAC+phy architecture, 2 is a MAC connected to >> > a phy over a serial link, 3 is a MAC connected to an optical >> > transcievber, and 4 is a backplane connection. A is the phy interface >> > mode, and B is the ethtool link mode. C is also the "phy interface >> > mode", except that sometimes it is highly-dependent on the link mode >> > (e.g. 1000BASE-X) and sometimes it is not (SGMII). The problem is case >> > 4. Here, there isn't really a phy interface mode; just a link mode. >> > >> > Consider the serdes driver. It has to know how to configure itself. >> > Sometimes this will be the phy mode (cases 2 and 3), and sometimes it >> > will be the link mode (case 4). In particular, for a link mode like >> > 1000BASE-SX, it should be configured for 1000BASE-X. But for >> > 1000BASE-KX, it has to be configured for 1000BASE-KX. I suppose the >> > right thing to do here is rework the phy subsystem to use link modes and >> > not phy modes for phy_mode_ext, since it seems like there is a >> > 1000BASE-X link mode. But what should be passed to mac_prepare and >> > mac_select_pcs? >> > >> > As another example, consider the AQR113C. It supports the following >> > (abbreviated) interfaces on the MAC side: >> > >> > - 10GBASE-KR >> > - 1000BASE-KX >> > - 10GBASE-R >> > - 1000BASE-X >> > - USXGMII >> > - SGMII >> > >> > This example of what phy-mode = "1000base-kx" would imply. I would >> > expect that selecting -KX over -X would change the electrical settings >> > to comply with clause 70 (instead of the SFP spec). >> >> Do you have any comments on the above? > > What comments do you expect? My message was just don't get sidetracked > by trying to tackle problems you don't need to solve, thinking they're > just there, along the way. > > "The problem" of wanting to describe an electrical using phy-mode was > discussed before, with debatable degrees of success and the following > synopsis: > > | phy_interface_t describes the protocol *only*, it doesn't describe > | the electrical characteristics of the interface. So, if we exclude > | the electrical characteristics of SFI, we're back to 10GBASE-R, > | 10GBASE-W, 10GFC or 10GBASE-R with FEC. That's what phy_interface_t > | is, not SFI. > | > | So, I propose that we add 10GBASE-R to the list and *not* SFI. > > https://lore.kernel.org/netdev/20191223105719.GM25745@shell.armlinux.org.uk/ > > I don't have access to 802.3 right now to double check, but I think this > is a similar case here - between 1000Base-SX and 1000Base-KX, only the > PMA/PMD is different, otherwise they are still both 1000Base-X in terms > of protocol/coding. Well, the main thing is that the PCS has to know we are doing c73 AN, as opposed to c37. Maybe we need another MLO_AN_? Or perhaps the PCS should look at the advertisement in order to determine how to advertise? But then who determines whether we do c73? This should really come from the device tree, and not involve userspace manually setting up the advertisement. And of course the serdes has to find out what the link mode is. I suppose we could stick this stuff in the device tree. Maybe using ethtool link modes for phy_set_mode_ext is better, but it's still not ideal since many link modes are electrically identical (we don't want to special-case full/half duplex in every serdes driver). > As for the second "example". I had opened my copy of the AQR113C manual > and IIRC it listed 10GBASE-KR in the system interfaces, but I don't > recall seeing 1000Base-KX. And even for 10GBASE-KR, there weren't a lot > of details, like what is configurable about it, is there C73 available etc. > Not extremely clear what that is about, tbh. Something that has > 10GBase-KR on system side and 10GBase-T on media side sounds like a > media converter to me. Not sure how we model those in phylib (I think > the answer is we don't). I'd agree with your assesment that it's a media converter and that the documentation isn't clear. However, it's fairly trivial to support in the manner I outlined. That's actually the main thing I'm getting at: the rest of the code is structured to treat a PHY_INTERFACE_MODE_1000BASEKX in the right way, even if it's not really a phy interface mode (...just like 1000BASE-X isn't really a phy interface mode). --Sean
diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c index 9bd69328dc4d..b08716fe22c1 100644 --- a/drivers/net/phy/phylink.c +++ b/drivers/net/phy/phylink.c @@ -344,6 +344,7 @@ void phylink_get_linkmodes(unsigned long *linkmodes, phy_interface_t interface, case PHY_INTERFACE_MODE_1000BASEX: caps |= MAC_1000HD; fallthrough; + case PHY_INTERFACE_MODE_1000BASEKX: case PHY_INTERFACE_MODE_TRGMII: caps |= MAC_1000FD; break; diff --git a/include/linux/phy.h b/include/linux/phy.h index 87638c55d844..81ce76c3e799 100644 --- a/include/linux/phy.h +++ b/include/linux/phy.h @@ -115,6 +115,7 @@ extern const int phy_10gbit_features_array[1]; * @PHY_INTERFACE_MODE_25GBASER: 25G BaseR * @PHY_INTERFACE_MODE_USXGMII: Universal Serial 10GE MII * @PHY_INTERFACE_MODE_10GKR: 10GBASE-KR - with Clause 73 AN + * @PHY_INTERFACE_MODE_1000BASEKX: 1000Base-KX - with Clause 73 AN * @PHY_INTERFACE_MODE_MAX: Book keeping * * Describes the interface between the MAC and PHY. @@ -152,6 +153,7 @@ typedef enum { PHY_INTERFACE_MODE_USXGMII, /* 10GBASE-KR - with Clause 73 AN */ PHY_INTERFACE_MODE_10GKR, + PHY_INTERFACE_MODE_1000BASEKX, PHY_INTERFACE_MODE_MAX, } phy_interface_t; @@ -249,6 +251,8 @@ static inline const char *phy_modes(phy_interface_t interface) return "trgmii"; case PHY_INTERFACE_MODE_1000BASEX: return "1000base-x"; + case PHY_INTERFACE_MODE_1000BASEKX: + return "1000base-kx"; case PHY_INTERFACE_MODE_2500BASEX: return "2500base-x"; case PHY_INTERFACE_MODE_5GBASER:
Add 1000BASE-KX interface mode. This 1G backplane ethernet as described in clause 70. Clause 73 autonegotiation is mandatory, and only full duplex operation is supported. Signed-off-by: Sean Anderson <sean.anderson@seco.com> --- (no changes since v1) drivers/net/phy/phylink.c | 1 + include/linux/phy.h | 4 ++++ 2 files changed, 5 insertions(+)