drivers/net/phy/aquantia_main.c | 136 ++++++++++++++++++++++++++++++-- drivers/net/phy/phy-core.c | 70 ++++++++++++++++ drivers/net/phy/phylink.c | 75 +----------------- include/linux/phy.h | 1 + include/uapi/linux/mdio.h | 118 ++++++++++++++++++--------- 5 files changed, 282 insertions(+), 118 deletions(-)
This attempts to address the problems first reported in [1]. Tim has an Aquantia phy where the firmware is set up to use "5G XFI" (underclocked 10GBASE-R) when rate adapting lower speeds. This results in us advertising that we support lower speeds and then failing to bring the link up. To avoid this, determine whether to enable rate adaptation based on what's programmed by the firmware. This is "the worst choice" [2], but we can't really do better until we have more insight into what the firmware is doing. At the very least, we can prevent bad firmware from causing us to advertise the wrong modes. Past submissions may be found at [3, 4]. [1] https://lore.kernel.org/netdev/CAJ+vNU3zeNqiGhjTKE8jRjDYR0D7f=iqPLB8phNyA2CWixy7JA@mail.gmail.com/ [2] https://lore.kernel.org/netdev/20221118171643.vu6uxbnmog4sna65@skbuf/ [3] https://lore.kernel.org/netdev/20221114210740.3332937-1-sean.anderson@seco.com/ [4] https://lore.kernel.org/netdev/20221128195409.100873-1-sean.anderson@seco.com/ Changes in v5: - Add missing PMA/PMD speed bits - Don't handle PHY_INTERFACE_MODE_NA, and simplify logic Changes in v4: - Reorganize MDIO defines - Fix kerneldoc using - instead of : for parameters Changes in v3: - Update speed register bits - Fix incorrect bits for PMA/PMD speed Changes in v2: - Move/rename phylink_interface_max_speed - Rework to just validate things instead of modifying registers Sean Anderson (4): net: phy: Move/rename phylink_interface_max_speed phy: mdio: Reorganize defines net: mdio: Update speed register bits phy: aquantia: Determine rate adaptation support from registers drivers/net/phy/aquantia_main.c | 136 ++++++++++++++++++++++++++++++-- drivers/net/phy/phy-core.c | 70 ++++++++++++++++ drivers/net/phy/phylink.c | 75 +----------------- include/linux/phy.h | 1 + include/uapi/linux/mdio.h | 118 ++++++++++++++++++--------- 5 files changed, 282 insertions(+), 118 deletions(-) -- 2.35.1.1320.gc452695387.dirty
On 1/3/23 17:05, Sean Anderson wrote: > This attempts to address the problems first reported in [1]. Tim has an > Aquantia phy where the firmware is set up to use "5G XFI" (underclocked > 10GBASE-R) when rate adapting lower speeds. This results in us > advertising that we support lower speeds and then failing to bring the > link up. To avoid this, determine whether to enable rate adaptation > based on what's programmed by the firmware. This is "the worst choice" > [2], but we can't really do better until we have more insight into > what the firmware is doing. At the very least, we can prevent bad > firmware from causing us to advertise the wrong modes. > > Past submissions may be found at [3, 4]. > > [1] https://lore.kernel.org/netdev/CAJ+vNU3zeNqiGhjTKE8jRjDYR0D7f=iqPLB8phNyA2CWixy7JA@mail.gmail.com/ > [2] https://lore.kernel.org/netdev/20221118171643.vu6uxbnmog4sna65@skbuf/ > [3] https://lore.kernel.org/netdev/20221114210740.3332937-1-sean.anderson@seco.com/ > [4] https://lore.kernel.org/netdev/20221128195409.100873-1-sean.anderson@seco.com/ > > Changes in v5: > - Add missing PMA/PMD speed bits > - Don't handle PHY_INTERFACE_MODE_NA, and simplify logic > > Changes in v4: > - Reorganize MDIO defines > - Fix kerneldoc using - instead of : for parameters > > Changes in v3: > - Update speed register bits > - Fix incorrect bits for PMA/PMD speed > > Changes in v2: > - Move/rename phylink_interface_max_speed > - Rework to just validate things instead of modifying registers > > Sean Anderson (4): > net: phy: Move/rename phylink_interface_max_speed > phy: mdio: Reorganize defines > net: mdio: Update speed register bits > phy: aquantia: Determine rate adaptation support from registers > > drivers/net/phy/aquantia_main.c | 136 ++++++++++++++++++++++++++++++-- > drivers/net/phy/phy-core.c | 70 ++++++++++++++++ > drivers/net/phy/phylink.c | 75 +----------------- > include/linux/phy.h | 1 + > include/uapi/linux/mdio.h | 118 ++++++++++++++++++--------- > 5 files changed, 282 insertions(+), 118 deletions(-) > Although there was a lot of discussion about the final patch, I think the first 3 are good changes. Can we apply them as-is? Should I resubmit? --Sean
Hi Sean, On Tue, Jan 03, 2023 at 05:05:07PM -0500, Sean Anderson wrote: > This attempts to address the problems first reported in [1]. Tim has an > Aquantia phy where the firmware is set up to use "5G XFI" (underclocked > 10GBASE-R) when rate adapting lower speeds. This results in us > advertising that we support lower speeds and then failing to bring the > link up. To avoid this, determine whether to enable rate adaptation > based on what's programmed by the firmware. This is "the worst choice" > [2], but we can't really do better until we have more insight into > what the firmware is doing. At the very least, we can prevent bad > firmware from causing us to advertise the wrong modes. After this patch set, is there any reason why phydev->rate_matching still exists and must be populated by the PHY driver?
On 1/5/23 08:39, Vladimir Oltean wrote: > Hi Sean, > > On Tue, Jan 03, 2023 at 05:05:07PM -0500, Sean Anderson wrote: >> This attempts to address the problems first reported in [1]. Tim has an >> Aquantia phy where the firmware is set up to use "5G XFI" (underclocked >> 10GBASE-R) when rate adapting lower speeds. This results in us >> advertising that we support lower speeds and then failing to bring the >> link up. To avoid this, determine whether to enable rate adaptation >> based on what's programmed by the firmware. This is "the worst choice" >> [2], but we can't really do better until we have more insight into >> what the firmware is doing. At the very least, we can prevent bad >> firmware from causing us to advertise the wrong modes. > > After this patch set, is there any reason why phydev->rate_matching > still exists and must be populated by the PHY driver? It's necessary for phylink_link_up to know what speed to use for the MAC. --Sean
© 2016 - 2024 Red Hat, Inc.