| Message ID | 20240619184550.34524-2-brgl@bgdev.pl (mailing list archive) |
|---|---|
| State | Changes Requested |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | net: support 2.5G ethernet in dwmac-qcom-ethqos | expand |
| Context | Check | Description |
|---|---|---|
| netdev/tree_selection | success | Clearly marked for net-next |
| netdev/apply | fail | Patch does not apply to net-next-0 |
On Wed, Jun 19, 2024 at 08:45:42PM +0200, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > > The Aquantia AQR115C PHY supports the Overlocked SGMII mode. In order to > support it in the driver, extend the PHY core with the new mode bits and > pieces. Here we go again.... Is this 2500BaseX but without inband signalling, since SGMII inband signalling makes no sense at 2.5G? Andrew
On Wed, Jun 19, 2024 at 9:09 PM Andrew Lunn <andrew@lunn.ch> wrote: > > On Wed, Jun 19, 2024 at 08:45:42PM +0200, Bartosz Golaszewski wrote: > > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > > > > The Aquantia AQR115C PHY supports the Overlocked SGMII mode. In order to > > support it in the driver, extend the PHY core with the new mode bits and > > pieces. > > Here we go again.... > Admittedly I don't post to net very often and I assume there's a story to this comment? Care to elaborate? Bart > Is this 2500BaseX but without inband signalling, since SGMII inband > signalling makes no sense at 2.5G? > > Andrew
On Wed, Jun 19, 2024 at 09:29:03PM +0200, Bartosz Golaszewski wrote: > On Wed, Jun 19, 2024 at 9:09 PM Andrew Lunn <andrew@lunn.ch> wrote: > > > > On Wed, Jun 19, 2024 at 08:45:42PM +0200, Bartosz Golaszewski wrote: > > > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > > > > > > The Aquantia AQR115C PHY supports the Overlocked SGMII mode. In order to > > > support it in the driver, extend the PHY core with the new mode bits and > > > pieces. > > > > Here we go again.... > > > > Admittedly I don't post to net very often and I assume there's a story > to this comment? Care to elaborate? 2.5G is a mess because vendors implemented it before the standard came out, in the form of 2500BaseX. They often did just what this seems to suggest, they overclocked CISCO SGMII. But the in-band signalling SGMII uses cannot work at 2.5G, it makes no sense. So vendors disable the in-band signalling. What you likely end up with, is 2500BaseX, but without in-band signalling. Now, some real 2500BaseX devices require the peer to perform in-band signalling. Some will listen for the signalling a while, and if they hear nothing will go into some sort of fallback mode. Others can be told the peer does not support inband signalling, and so don't expect it. And then we have those which are overclocked SGMII which don't expect any signalling because SGMII signalling makes no sense at 2.5G. phylib supports out of band signalling, which is enough to make this work, so long as two peers will actually establish a link because they are sufficiently tolerant of what the other end is doing. Sometimes they need a hint. Russell King has been working on this mess, and i'm sure he will be along soon. What i expect will happen is you keep calling this 2500BaseX, without in band signalling. You can look back in the netdev mailling list for more details and those that have been here before you. It is always good to search the history, otherwise you are just going to repeat it. Andrew
On Wed, Jun 19, 2024 at 09:51:12PM +0200, Andrew Lunn wrote: > phylib supports out of band signalling, which is enough to make this > work, so long as two peers will actually establish a link because they > are sufficiently tolerant of what the other end is doing. Sometimes > they need a hint. Russell King has been working on this mess, and i'm > sure he will be along soon. ... and I'm rolling my eyes, wondering whether I will get time to finish the code that I started any time soon. I'll note that the more hacky code we end up merging, the harder it will become to solve this problem (and we already have several differing behaviours merged with 2500base-X already.) > What i expect will happen is you keep calling this 2500BaseX, without > in band signalling. You can look back in the netdev mailling list for > more details and those that have been here before you. It is always > good to search the history, otherwise you are just going to repeat it. That's where things start getting sticky, because at the moment, phylink expects 2500base-X to be like 1000base-X, and be a media interface mode rather than a MAC-to-PHY interface mode. This is partly what my patches will address if I can get around to finishing them - but at this point I really do not know when that will be. I still have the high priority work problem that I'm actively involved with. I may have three weeks holiday at the start of July (and I really need it right now!) Then, there's possibly quite a lot of down time in August because I'm having early cataract ops which will substantially change my eye sight. There's two possible outcomes from that. The best case is that in just over two weeks after the first op, I'll be able to read the screen without glasses. The worst case is that I have to wait a further two to three weeks to see my optometrist (assuming he has availability), and then wait for replacement lenses to be made up, fitted and the new glasses sent. So, I'm only finding the occasional time to be able to look at mainline stuff, and I don't see that changing very much until maybe September. At this point, I think we may as well give up and let people do whatever they want to do with 2500base-X (which is basically what we're already doing), and when they have compatibility problems... well... really not much we can do about that, and it will be way too late to try and sort the mess out.
On Wed, Jun 19, 2024 at 10:07:21PM GMT, Russell King (Oracle) wrote: > On Wed, Jun 19, 2024 at 09:51:12PM +0200, Andrew Lunn wrote: > > phylib supports out of band signalling, which is enough to make this > > work, so long as two peers will actually establish a link because they > > are sufficiently tolerant of what the other end is doing. Sometimes > > they need a hint. Russell King has been working on this mess, and i'm > > sure he will be along soon. > > ... and I'm rolling my eyes, wondering whether I will get time to > finish the code that I started any time soon. I'll note that the more > hacky code we end up merging, the harder it will become to solve this > problem (and we already have several differing behaviours merged with > 2500base-X already.) > > > What i expect will happen is you keep calling this 2500BaseX, without > > in band signalling. You can look back in the netdev mailling list for > > more details and those that have been here before you. It is always > > good to search the history, otherwise you are just going to repeat it. > > That's where things start getting sticky, because at the moment, > phylink expects 2500base-X to be like 1000base-X, and be a media > interface mode rather than a MAC-to-PHY interface mode. This is partly > what my patches will address if I can get around to finishing them - > but at this point I really do not know when that will be. > > I still have the high priority work problem that I'm actively involved > with. I may have three weeks holiday at the start of July (and I really > need it right now!) Then, there's possibly quite a lot of down time in > August because I'm having early cataract ops which will substantially > change my eye sight. There's two possible outcomes from that. The best > case is that in just over two weeks after the first op, I'll be able to > read the screen without glasses. The worst case is that I have to wait > a further two to three weeks to see my optometrist (assuming he has > availability), and then wait for replacement lenses to be made up, > fitted and the new glasses sent. > > So, I'm only finding the occasional time to be able to look at > mainline stuff, and I don't see that changing very much until maybe > September. > > At this point, I think we may as well give up and let people do > whatever they want to do with 2500base-X (which is basically what we're > already doing), and when they have compatibility problems... well... > really not much we can do about that, and it will be way too late to > try and sort the mess out. I hope your holiday and operation go well Russell. Pardon my ignorance, but I know of quite a few things you have in flight and because of that I'm not entirely sure what specific patches you're referring to above. Have those hit the list? I know you're cleaning up stmmac's phylink/pcs usage, but I'm thinking that this is outside of that series. Thanks in advance for helping me understand all that's in progress around this mess of a topic!
On Thu, Jun 20, 2024 at 02:42:41PM GMT, Andrew Halaney wrote: > On Wed, Jun 19, 2024 at 10:07:21PM GMT, Russell King (Oracle) wrote: > > On Wed, Jun 19, 2024 at 09:51:12PM +0200, Andrew Lunn wrote: > > > phylib supports out of band signalling, which is enough to make this > > > work, so long as two peers will actually establish a link because they > > > are sufficiently tolerant of what the other end is doing. Sometimes > > > they need a hint. Russell King has been working on this mess, and i'm > > > sure he will be along soon. > > > > ... and I'm rolling my eyes, wondering whether I will get time to > > finish the code that I started any time soon. I'll note that the more > > hacky code we end up merging, the harder it will become to solve this > > problem (and we already have several differing behaviours merged with > > 2500base-X already.) > > > > > What i expect will happen is you keep calling this 2500BaseX, without > > > in band signalling. You can look back in the netdev mailling list for > > > more details and those that have been here before you. It is always > > > good to search the history, otherwise you are just going to repeat it. > > > > That's where things start getting sticky, because at the moment, > > phylink expects 2500base-X to be like 1000base-X, and be a media > > interface mode rather than a MAC-to-PHY interface mode. This is partly > > what my patches will address if I can get around to finishing them - > > but at this point I really do not know when that will be. > > > > I still have the high priority work problem that I'm actively involved > > with. I may have three weeks holiday at the start of July (and I really > > need it right now!) Then, there's possibly quite a lot of down time in > > August because I'm having early cataract ops which will substantially > > change my eye sight. There's two possible outcomes from that. The best > > case is that in just over two weeks after the first op, I'll be able to > > read the screen without glasses. The worst case is that I have to wait > > a further two to three weeks to see my optometrist (assuming he has > > availability), and then wait for replacement lenses to be made up, > > fitted and the new glasses sent. > > > > So, I'm only finding the occasional time to be able to look at > > mainline stuff, and I don't see that changing very much until maybe > > September. > > > > At this point, I think we may as well give up and let people do > > whatever they want to do with 2500base-X (which is basically what we're > > already doing), and when they have compatibility problems... well... > > really not much we can do about that, and it will be way too late to > > try and sort the mess out. > > I hope your holiday and operation go well Russell. > > Pardon my ignorance, but I know of quite a few things you have in flight > and because of that I'm not entirely sure what specific patches you're > referring to above. Have those hit the list? I know you're cleaning > up stmmac's phylink/pcs usage, but I'm thinking that this is outside of > that series. Thanks in advance for helping me understand all that's in > progress around this mess of a topic! Nevermind my question, I was talking a little about this today with respect to a Renesas board as well (can't escape it it seems) and in going through our convos I found: https://lore.kernel.org/netdev/ZlNi11AsdDpKM6AM@shell.armlinux.org.uk/ """ I do have some work-in-progress patches that attempt to sort this out in phylink and identify incompatible situations. See http://git.armlinux.org.uk/cgit/linux-arm.git/log/?h=net-queue commits (I think)... net: phylink: clean up phylink_resolve() to: net: phylink: switch to MLO_AN_PHY when PCS uses outband and since I'm converting stmmac's hacky PCS that bypasses phylink to a real phylink_pcs, the ethqos code as it stands presents a blocker because of this issue. So, I'm intending to post a series in the next few days (after the bank holiday) and will definitely need to be tested on ethqos hardware. """ Thanks, Andrew
diff --git a/drivers/net/phy/phy-core.c b/drivers/net/phy/phy-core.c index 15f349e5995a..7cf87cae11f0 100644 --- a/drivers/net/phy/phy-core.c +++ b/drivers/net/phy/phy-core.c @@ -138,6 +138,7 @@ int phy_interface_num_ports(phy_interface_t interface) case PHY_INTERFACE_MODE_RXAUI: case PHY_INTERFACE_MODE_XAUI: case PHY_INTERFACE_MODE_1000BASEKX: + case PHY_INTERFACE_MODE_OCSGMII: return 1; case PHY_INTERFACE_MODE_QSGMII: case PHY_INTERFACE_MODE_QUSGMII: diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c index 02427378acfd..ce07d41a233f 100644 --- a/drivers/net/phy/phylink.c +++ b/drivers/net/phy/phylink.c @@ -128,6 +128,7 @@ static const phy_interface_t phylink_sfp_interface_preference[] = { PHY_INTERFACE_MODE_5GBASER, PHY_INTERFACE_MODE_2500BASEX, PHY_INTERFACE_MODE_SGMII, + PHY_INTERFACE_MODE_OCSGMII, PHY_INTERFACE_MODE_1000BASEX, PHY_INTERFACE_MODE_100BASEX, }; @@ -180,6 +181,7 @@ static unsigned int phylink_interface_signal_rate(phy_interface_t interface) switch (interface) { case PHY_INTERFACE_MODE_SGMII: case PHY_INTERFACE_MODE_1000BASEX: /* 1.25Mbd */ + case PHY_INTERFACE_MODE_OCSGMII: return 1250; case PHY_INTERFACE_MODE_2500BASEX: /* 3.125Mbd */ return 3125; @@ -231,6 +233,7 @@ static int phylink_interface_max_speed(phy_interface_t interface) return SPEED_1000; case PHY_INTERFACE_MODE_2500BASEX: + case PHY_INTERFACE_MODE_OCSGMII: return SPEED_2500; case PHY_INTERFACE_MODE_5GBASER: @@ -515,6 +518,10 @@ static unsigned long phylink_get_capabilities(phy_interface_t interface, caps |= MAC_1000HD | MAC_1000FD; fallthrough; + case PHY_INTERFACE_MODE_OCSGMII: + caps |= MAC_2500FD; + fallthrough; + case PHY_INTERFACE_MODE_REVRMII: case PHY_INTERFACE_MODE_RMII: case PHY_INTERFACE_MODE_SMII: @@ -929,6 +936,7 @@ static int phylink_parse_mode(struct phylink *pl, case PHY_INTERFACE_MODE_10GKR: case PHY_INTERFACE_MODE_10GBASER: case PHY_INTERFACE_MODE_XLGMII: + case PHY_INTERFACE_MODE_OCSGMII: caps = ~(MAC_SYM_PAUSE | MAC_ASYM_PAUSE); caps = phylink_get_capabilities(pl->link_config.interface, caps, RATE_MATCH_NONE); @@ -1357,7 +1365,8 @@ static void phylink_mac_initial_config(struct phylink *pl, bool force_restart) case MLO_AN_INBAND: link_state = pl->link_config; - if (link_state.interface == PHY_INTERFACE_MODE_SGMII) + if (link_state.interface == PHY_INTERFACE_MODE_SGMII || + link_state.interface == PHY_INTERFACE_MODE_OCSGMII) link_state.pause = MLO_PAUSE_NONE; break; @@ -3640,6 +3649,7 @@ void phylink_mii_c22_pcs_decode_state(struct phylink_link_state *state, break; case PHY_INTERFACE_MODE_SGMII: + case PHY_INTERFACE_MODE_OCSGMII: case PHY_INTERFACE_MODE_QSGMII: phylink_decode_sgmii_word(state, lpa); break; @@ -3715,6 +3725,7 @@ int phylink_mii_c22_pcs_encode_advertisement(phy_interface_t interface, adv |= ADVERTISE_1000XPSE_ASYM; return adv; case PHY_INTERFACE_MODE_SGMII: + case PHY_INTERFACE_MODE_OCSGMII: case PHY_INTERFACE_MODE_QSGMII: return 0x0001; default: diff --git a/include/linux/phy.h b/include/linux/phy.h index e6e83304558e..73da0983d631 100644 --- a/include/linux/phy.h +++ b/include/linux/phy.h @@ -128,6 +128,7 @@ extern const int phy_10gbit_features_array[1]; * @PHY_INTERFACE_MODE_10GKR: 10GBASE-KR - with Clause 73 AN * @PHY_INTERFACE_MODE_QUSGMII: Quad Universal SGMII * @PHY_INTERFACE_MODE_1000BASEKX: 1000Base-KX - with Clause 73 AN + * @PHY_INTERFACE_MODE_OCSGMII: Overclocked SGMII * @PHY_INTERFACE_MODE_MAX: Book keeping * * Describes the interface between the MAC and PHY. @@ -168,6 +169,7 @@ typedef enum { PHY_INTERFACE_MODE_10GKR, PHY_INTERFACE_MODE_QUSGMII, PHY_INTERFACE_MODE_1000BASEKX, + PHY_INTERFACE_MODE_OCSGMII, PHY_INTERFACE_MODE_MAX, } phy_interface_t; @@ -289,6 +291,8 @@ static inline const char *phy_modes(phy_interface_t interface) return "100base-x"; case PHY_INTERFACE_MODE_QUSGMII: return "qusgmii"; + case PHY_INTERFACE_MODE_OCSGMII: + return "ocsgmii"; default: return "unknown"; }