| Message ID | 20210212172341.3489046-1-olteanv@gmail.com |
|---|---|
| Headers | show |
| Series | Let phylink manage in-band AN for the PHY | expand |
On Fri, Feb 12, 2021 at 11:40:59PM +0100, Michael Walle wrote: > Fun fact, now it may be the other way around. If the bootloader doesn't > configure it and the PHY isn't reset by the hardware, it won't work in > the bootloader after a reboot ;) If we start messing around with the configuration of PHYs in that regard, we could be opening ourselves up for a world of pain... > If you disable aneg between MAC and PHY, what would be the actual speed > setting/duplex mode then? I guess it have to match the external speed? That is a function of the interface mode and the PHY capabilities. 1) if the PHY supports rate adaption, and is programmed for that, then the PHY link normally operates at a fixed speed (e.g. 1G for SGMII) and the PHY converts to the appropriate speed. We don't actually support this per se, since the parameters we give to the MAC via mac_link_up() are the media side parameters, not the link parameters. 2) if the PHY does not support rate adaption, then the MAC to PHY link needs to follow the media speed and duplex. phylink will be in "PHY" mode, where it passes the media side negotiation results to the MAC just like phylib would, and the MAC should be programmed appropriately. In the case of a SGMII link, the link needs to be programmed to do the appropriate symbol repetition for 100M and 10M speeds. The PHY /should/ do that automatically, but if it doesn't, then the PHY also needs to be programmed to conform. (since if there's no rate adaption in the PHY, the MAC side and the media side must match.) Hope that helps. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
On Fri, Feb 12, 2021 at 11:40:59PM +0100, Michael Walle wrote: > Am 2021-02-12 18:23, schrieb Vladimir Oltean: > > From: Vladimir Oltean <vladimir.oltean@nxp.com> > > > > Currently Linux has no control over whether a MAC-to-PHY interface uses > > in-band signaling or not, even though phylink has the > > managed = "in-band-status"; > > property which denotes that the MAC expects in-band signaling to be > > used. > > > > The problem is really that if the in-band signaling is configurable in > > both the PHY and the MAC, there is a risk that they are out of sync > > unless phylink manages them both. Most if not all in-band autoneg state > > machines follow IEEE 802.3 clause 37, which means that they will not > > change the operating mode of the SERDES lane from control to data mode > > unless in-band AN completed successfully. Therefore traffic will not > > work. > > > > It is particularly unpleasant that currently, we assume that PHYs which > > have configurable in-band AN come pre-configured from a prior boot stage > > such as U-Boot, because once the bootloader changes, all bets are off. > > Fun fact, now it may be the other way around. If the bootloader doesn't > configure it and the PHY isn't reset by the hardware, it won't work in > the bootloader after a reboot ;) My understanding is that this is precisely the reason why the U-Boot people don't want to support booting from RAM, and want to assume that the nothing else ran between Power On Reset and the bootloader: https://www.denx.de/wiki/view/DULG/CanUBootBeConfiguredSuchThatItCanBeStartedInRAM [ that does make me wonder what they think about ARM TF-A ] > > Let's introduce a new PHY driver method for configuring in-band autoneg, > > and make phylink be its first user. The main PHY library does not call > > phy_config_inband_autoneg, because it does not know what to configure it > > to. Presumably, non-phylink drivers can also call > > phy_config_inband_autoneg > > individually. > > If you disable aneg between MAC and PHY, what would be the actual speed > setting/duplex mode then? I guess it have to match the external speed? > > I'm trying this on the AT8031. I've removed 'managed = "in-band-status";' > for the PHY. Confirmed that it won't work and then I've implemented your > new callback. That will disable the SGMII aneg (which is done via the > BMCR of fiber page if I'm not entirely mistaken); ethernet will then > work again. But only for gigabit. I presume because the speed setting > of the SGMII link is set to gigabit. Which MAC driver are you testing on? Are you saying that it doesn't force the link to the speed resolved over MDIO and passed to .phylink_mac_link_up, or that the speed communicated to it is incorrect?
Am 2021-02-13 01:18, schrieb Russell King - ARM Linux admin: > On Fri, Feb 12, 2021 at 11:40:59PM +0100, Michael Walle wrote: >> Fun fact, now it may be the other way around. If the bootloader >> doesn't >> configure it and the PHY isn't reset by the hardware, it won't work in >> the bootloader after a reboot ;) > > If we start messing around with the configuration of PHYs in that > regard, we could be opening ourselves up for a world of pain... > >> If you disable aneg between MAC and PHY, what would be the actual >> speed >> setting/duplex mode then? I guess it have to match the external speed? > > That is a function of the interface mode and the PHY capabilities. > > 1) if the PHY supports rate adaption, and is programmed for that, then > the PHY link normally operates at a fixed speed (e.g. 1G for SGMII) > and the PHY converts to the appropriate speed. > > We don't actually support this per se, since the parameters we give > to the MAC via mac_link_up() are the media side parameters, not the > link parameters. > > 2) if the PHY does not support rate adaption, then the MAC to PHY link > needs to follow the media speed and duplex. phylink will be in "PHY" > mode, where it passes the media side negotiation results to the MAC > just like phylib would, and the MAC should be programmed > appropriately. In the case of a SGMII link, the link needs to be > programmed to do the appropriate symbol repetition for 100M and 10M > speeds. The PHY /should/ do that automatically, but if it doesn't, > then the PHY also needs to be programmed to conform. (since if > there's no rate adaption in the PHY, the MAC side and the media side > must match.) Thanks, but I'm not sure I understand the difference between "rate adaption" and symbol repetition. The SGMII link is always 1.25Gb, right? If the media side is 100Mbit it will repeat the symbol 10 times or 100 times in case of 10Mbit. What is "rate adaption" then? -- -michael
Am 2021-02-13 01:36, schrieb Vladimir Oltean: > On Fri, Feb 12, 2021 at 11:40:59PM +0100, Michael Walle wrote: >> Am 2021-02-12 18:23, schrieb Vladimir Oltean: >> > From: Vladimir Oltean <vladimir.oltean@nxp.com> >> > >> > Currently Linux has no control over whether a MAC-to-PHY interface uses >> > in-band signaling or not, even though phylink has the >> > managed = "in-band-status"; >> > property which denotes that the MAC expects in-band signaling to be >> > used. >> > >> > The problem is really that if the in-band signaling is configurable in >> > both the PHY and the MAC, there is a risk that they are out of sync >> > unless phylink manages them both. Most if not all in-band autoneg state >> > machines follow IEEE 802.3 clause 37, which means that they will not >> > change the operating mode of the SERDES lane from control to data mode >> > unless in-band AN completed successfully. Therefore traffic will not >> > work. >> > >> > It is particularly unpleasant that currently, we assume that PHYs which >> > have configurable in-band AN come pre-configured from a prior boot stage >> > such as U-Boot, because once the bootloader changes, all bets are off. >> >> Fun fact, now it may be the other way around. If the bootloader >> doesn't >> configure it and the PHY isn't reset by the hardware, it won't work in >> the bootloader after a reboot ;) > > My understanding is that this is precisely the reason why the U-Boot > people don't want to support booting from RAM, and want to assume that > the nothing else ran between Power On Reset and the bootloader: > https://www.denx.de/wiki/view/DULG/CanUBootBeConfiguredSuchThatItCanBeStartedInRAM > [ that does make me wonder what they think about ARM TF-A ] It isn't that easy sometimes. Eg. there might be boards without a proper reset of the peripherals, maybe the SoC will just generate an internal reset, whatever. One might conisder that a broken board. But, for example, on the kontron sl28, we deliberatly chose not to do a PHY reset (well it is actually configurable) because this will also prevent WoL by the PHY. >> > Let's introduce a new PHY driver method for configuring in-band autoneg, >> > and make phylink be its first user. The main PHY library does not call >> > phy_config_inband_autoneg, because it does not know what to configure it >> > to. Presumably, non-phylink drivers can also call >> > phy_config_inband_autoneg >> > individually. >> >> If you disable aneg between MAC and PHY, what would be the actual >> speed >> setting/duplex mode then? I guess it have to match the external speed? >> >> I'm trying this on the AT8031. I've removed 'managed = >> "in-band-status";' >> for the PHY. Confirmed that it won't work and then I've implemented >> your >> new callback. That will disable the SGMII aneg (which is done via the >> BMCR of fiber page if I'm not entirely mistaken); ethernet will then >> work again. But only for gigabit. I presume because the speed setting >> of the SGMII link is set to gigabit. > > Which MAC driver are you testing on? enetc > Are you saying that it doesn't > force the link to the speed resolved over MDIO and passed to > .phylink_mac_link_up, or that the speed communicated to it is > incorrect? That seem to work: [ 5313.852406] fsl_enetc 0000:00:00.0 gbe0: phy link down sgmii/Unknown/Unknown [ 5313.852414] fsl_enetc 0000:00:00.0 gbe0: Link is Down [ 5315.900687] fsl_enetc 0000:00:00.0 gbe0: phy link up sgmii/100Mbps/Full [ 5315.916816] fsl_enetc 0000:00:00.0 gbe0: Link is Up - 100Mbps/Full - flow control rx/tx But the Atheros PHY seems to have a problem with the SGMII link if there is no autoneg. No matter what I do, I can't get any traffic though if its not gigabit on the copper side. Unfortunately, I don't have access to an oscilloscope right now to see whats going on on the SGMII link. -michael
> Thanks, but I'm not sure I understand the difference between "rate > adaption" and symbol repetition. The SGMII link is always 1.25Gb, > right? If the media side is 100Mbit it will repeat the symbol 10 > times or 100 times in case of 10Mbit. What is "rate adaption" then? Hi Michael Some multiG PHYs fix their host side interface to say 10Gbps, independent of what the media side is doing. The PHY adapts the 10Gbps stream it gets from the host down to 10Mbps etc as needed, dropping frames if its internal buffers overflow. Andrew
On Sat, Feb 13, 2021 at 05:41:55PM +0100, Michael Walle wrote: > Am 2021-02-13 01:18, schrieb Russell King - ARM Linux admin: > > That is a function of the interface mode and the PHY capabilities. > > > > 1) if the PHY supports rate adaption, and is programmed for that, then > > the PHY link normally operates at a fixed speed (e.g. 1G for SGMII) > > and the PHY converts to the appropriate speed. > > > > We don't actually support this per se, since the parameters we give > > to the MAC via mac_link_up() are the media side parameters, not the > > link parameters. > > > > 2) if the PHY does not support rate adaption, then the MAC to PHY link > > needs to follow the media speed and duplex. phylink will be in "PHY" > > mode, where it passes the media side negotiation results to the MAC > > just like phylib would, and the MAC should be programmed > > appropriately. In the case of a SGMII link, the link needs to be > > programmed to do the appropriate symbol repetition for 100M and 10M > > speeds. The PHY /should/ do that automatically, but if it doesn't, > > then the PHY also needs to be programmed to conform. (since if > > there's no rate adaption in the PHY, the MAC side and the media side > > must match.) > > Thanks, but I'm not sure I understand the difference between "rate > adaption" and symbol repetition. The SGMII link is always 1.25Gb, > right? If the media side is 100Mbit it will repeat the symbol 10 > times or 100 times in case of 10Mbit. What is "rate adaption" then? You are correct about SGMII. Bear in mind that there is very little difference between SGMII and 1000base-X when you don't have AN. SGMII can be forced to do the symbol repetition. Symbol repetition does not exist in 1000base-X. Some PHYs, particularly 10G multi-speed PHYs, have a "rate adaption" block that can be used when the media side is operating at slower- than-10G speed when the media side is fixed at 10G. What this means is the MAC side always operates at full 10G speed, but the PHY queues packets for transmission at the media rate. Received packets are received by the PHY and then forwarded to the MAC at 10G speed. To add to that, some PHYs have the ability to send pause frames when their internal buffer fills up. Others stipulate that the MAC needs to rate-limit the transmitted packets to match the media side speed. Whether such a feature exists in 1G PHYs is unknown. If a PHY is capable of 1G/100M/10M speeds, but if SGMII AN is disabled and there is no way to force the symbol repetition, the SGMII side will be fixed at 1G speed. The only way this can work with a slower media speed is if the PHY performs rate adaption internally, converting between the 1G speed on the host side and whatever speed the media side is operating. So, for example, if the PHY was to have rate adaption, the media side would operate at 100M but the MAC side would continue operating at 1G speed without symbol repetition. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
Am 2021-02-13 17:53, schrieb Michael Walle: > Am 2021-02-13 01:36, schrieb Vladimir Oltean: > But the Atheros PHY seems to have a problem with the SGMII link > if there is no autoneg. > No matter what I do, I can't get any traffic though if its not > gigabit on the copper side. Unfortunately, I don't have access > to an oscilloscope right now to see whats going on on the SGMII > link. Scrap that. It will work if I set the speed/duplex mode in BMCR correctly. (I tried that before, but I shifted one bit. doh). So that will work, but when will it be done? There is no callback to configure the PCS side of the PHY if a link up is detected. -michael
On Sat, Feb 13, 2021 at 06:09:13PM +0100, Michael Walle wrote: > Am 2021-02-13 17:53, schrieb Michael Walle: > > Am 2021-02-13 01:36, schrieb Vladimir Oltean: > > But the Atheros PHY seems to have a problem with the SGMII link > > if there is no autoneg. > > No matter what I do, I can't get any traffic though if its not > > gigabit on the copper side. Unfortunately, I don't have access > > to an oscilloscope right now to see whats going on on the SGMII > > link. > > Scrap that. It will work if I set the speed/duplex mode in BMCR > correctly. (I tried that before, but I shifted one bit. doh). > > So that will work, but when will it be done? There is no > callback to configure the PCS side of the PHY if a link up is > detected. That's interesting/odd, on VSC8514 there is no need to force the speed of the system side to what was negotiated on media side. I took a quick look through the AR8033 datasheet and there isn't any mentioning the ability to program the SGMII link according to internal state as opposed to register settings, but it's equally possible that I'm simply not seeing it. On the other hand, I never meant for the inband autoneg setting to only be configurable both ways. I expect some PHYs are not able to operate using noinband mode, and for those I guess you should simply return -EINVAL, allowing the system designer to know that the configuration will not work and why. I think you could hook into .config_aneg_done, for the autoneg=true case, and into .config_aneg for autoneg=false (I'm talking about autoneg on media side here), but honestly I think the PHY is pretty broken for requiring external coordination between the clause 28 and the clause 37 PCS. So unless there is a real need to configure noinband mode, I would probably not bother.
Am 2021-02-13 19:56, schrieb Vladimir Oltean: > On Sat, Feb 13, 2021 at 06:09:13PM +0100, Michael Walle wrote: >> Am 2021-02-13 17:53, schrieb Michael Walle: >> > Am 2021-02-13 01:36, schrieb Vladimir Oltean: >> > But the Atheros PHY seems to have a problem with the SGMII link >> > if there is no autoneg. >> > No matter what I do, I can't get any traffic though if its not >> > gigabit on the copper side. Unfortunately, I don't have access >> > to an oscilloscope right now to see whats going on on the SGMII >> > link. >> >> Scrap that. It will work if I set the speed/duplex mode in BMCR >> correctly. (I tried that before, but I shifted one bit. doh). >> >> So that will work, but when will it be done? There is no >> callback to configure the PCS side of the PHY if a link up is >> detected. > > That's interesting/odd, on VSC8514 there is no need to force the speed > of the system side to what was negotiated on media side. I took a quick > look through the AR8033 datasheet and there isn't any mentioning the > ability to program the SGMII link according to internal state as > opposed > to register settings, but it's equally possible that I'm simply not > seeing it. I couldn't find anything in the AR8031 datasheet either. > On the other hand, I never meant for the inband autoneg setting to only > be configurable both ways. Then why is there a "bool enabled"? > I expect some PHYs are not able to operate > using noinband mode, and for those I guess you should simply return > -EINVAL, allowing the system designer to know that the configuration > will not work and why. You mean like this: static int at803x_config_inband_aneg(struct phy_device *phydev, bool enabled) { if (!enabled) return -EINVAL; /* enable SGMII autoneg */ return phy_write_paged(...); } But then why bother with config_inband_aneg() at all and just enable it unconditionally in config_init(). [and maybe keep the return -EINVAL]. Which then begs the question, does it makes sense on (Q)SGMII links at all? > I think you could hook into .config_aneg_done, for the autoneg=true > case, and into .config_aneg for autoneg=false (I'm talking about > autoneg > on media side here), but honestly I think the PHY is pretty broken for > requiring external coordination between the clause 28 and the clause 37 > PCS. So unless there is a real need to configure noinband mode, I would > probably not bother. Probably not. -michael
On Sat, Feb 13, 2021 at 08:57:46PM +0100, Michael Walle wrote: > > On the other hand, I never meant for the inband autoneg setting to only > > be configurable both ways. > > Then why is there a "bool enabled"? Let me stress the word _only_ both ways. The whole point of the "bool enabled" is to attempt coordination with the 'managed = "in-band-status"' property device tree property of the MAC, or to error out if it is not possible. > > I expect some PHYs are not able to operate > > using noinband mode, and for those I guess you should simply return > > -EINVAL, allowing the system designer to know that the configuration > > will not work and why. > > You mean like this: > > static int at803x_config_inband_aneg(struct phy_device *phydev, bool > enabled) > { > if (!enabled) > return -EINVAL; > /* enable SGMII autoneg */ > return phy_write_paged(...); > } > > But then why bother with config_inband_aneg() at all and just enable > it unconditionally in config_init(). [and maybe keep the return -EINVAL]. Because .config_init() is generic code, while .config_inband_autoneg() is phylink-specific. Generally I don't want to make any assumption about the state in which a PHY driver used to operate prior to this series. If you are sure that at803x.c user relies on a prior bootloader stage having disabled in-band AN, then sure, I suppose you can enable it unconditionally in .config_init(). For VSC8514 I put the configuration deliberately in a phylink-specific callback since I trust that at least the MAC-side drivers were reviewed for proper use of MLO_AN_PHY vs MLO_AN_INBAND. > Which then begs the question, does it makes sense on (Q)SGMII links at > all? See above. In the general case we need to assume a wild world where the same PHY driver operates as inband on some platforms and noinband on others (and most importantly, it works on both, which we'd like to preserve at least). I would be glad if we didn't need to make that assumption though.
On Sat, Feb 13, 2021 at 08:57:46PM +0100, Michael Walle wrote: > But then why bother with config_inband_aneg() at all and just enable > it unconditionally in config_init(). [and maybe keep the return -EINVAL]. > Which then begs the question, does it makes sense on (Q)SGMII links at > all? There are three cases. There are PHYs which operate in SGMII mode: 1) with in-band signalling enabled or disabled. 2) only with in-band signalling enabled. 3) with no in-band signalling capability. Most Marvell PHYs can be configured and fall into class (1), although changing that configuration is disruptive to the entire PHY. There is at least one Broadcom PHY we support that falls into class (3) and it appears on SFP modules. It sounds like AR803x fall into class (2). -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
From: Vladimir Oltean <vladimir.oltean@nxp.com> This small series creates a configuration knob for PHY drivers which use serial MII-side interfaces and support clause 37 in-band auto-negotiation there. Vladimir Oltean (2): net: phylink: explicitly configure in-band autoneg for PHYs that support it net: phy: mscc: configure in-band auto-negotiation for VSC8514 drivers/net/phy/mscc/mscc.h | 2 ++ drivers/net/phy/mscc/mscc_main.c | 13 +++++++++++++ drivers/net/phy/phy.c | 12 ++++++++++++ drivers/net/phy/phylink.c | 8 ++++++++ include/linux/phy.h | 8 ++++++++ 5 files changed, 43 insertions(+)