Messages in this thread | | | Date | Thu, 5 Jan 2023 19:43:42 +0200 | From | Vladimir Oltean <> | Subject | Re: [PATCH net-next v5 4/4] phy: aquantia: Determine rate adaptation support from registers |
| |
On Thu, Jan 05, 2023 at 02:40:50PM +0000, Russell King (Oracle) wrote: > > If the PHY firmware uses a combination like this: 10GBASE-R/XFI for > > media speeds of 10G, 5G, 2.5G (rate adapted), and SGMII for 1G, 100M > > and 10M, a call to your implementation of > > aqr107_get_rate_matching(PHY_INTERFACE_MODE_10GBASER) would return > > RATE_MATCH_NONE, right? So only ETHTOOL_LINK_MODE_10000baseT_Full_BIT > > would be advertised on the media side? > > No, beause of the special condition in phylink that if it's a clause 45 > PHY and we use something like 10GBASE-R, we don't limit to just 10G > speed, but try all interface modes - on the assumption that the PHY > will switch its host interface. > > RATE_MATCH_NONE doesn't state anything about whether the PHY operates > in a single interface mode or not - with 10G PHYs (and thus clause 45 > PHYs) it seems very common from current observations for > implementations to do this kind of host-interface switching.
So you mention commits 7642cc28fd37 ("net: phylink: fix PHY validation with rate adaption") and df3f57ac9605 ("net: phylink: extend clause 45 PHY validation workaround").
IIUC, these allow the advertised capabilities to be more than 10G (based on supported_interfaces), on the premise that it's possible for the PHY to switch SERDES protocol to achieve lower speeds.
This does partly correct the last part of my question, but I believe that the essence of it still remains. We won't make use of PAUSE rate adaptation to support the speeds which aren't directly covered by the supported_interfaces. Aren't we interpreting the PHY provisioning somewhat too conservatively in this case, or do you believe that this is just an academic concern?
| |