| Message ID | 20190207094939.27369-1-maxime.chevallier@bootlin.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | net: phy: Add support for 2.5GBASET PHYs | expand |
On 07.02.2019 10:49, Maxime Chevallier wrote: > Hello everyone, > > This is the second iteration of the series introducing support for > 2.5GBASET and 5GBASET to the network PHY infrastructure. > > These 2 modes are described in the 802.3bz specifications, and allow to > use 2.5G and 5G speeds on cat5e/cat6 cables. > > The required infrastructure code is added for 2.5GBASET and 5GBASET, but > only 2.5GBASET support is added to the Marvell10G driver. The reason is > because the 5GBASER interface mode used to communicate with the MAC > isn't implemented yet, and therefore this can't be tested. > > This series has seen some rework since last time, see the full details > in the patches changelog. The main highlights are : > > - Patch 1 moves the Pause ans Asym_Pause parameters update after > calling config_init. This allows us to change the phydev->supported > modes in config_init, while still forcing some quirks taken from > phydrv->features, to disable unsupported Pause modes. This was > proposed by Andrew. > > - Patch 2 generalizes the way we mask-out modes we don't want to use > when forcing the link speed through DT or ethtool, by walking through > the PHY settings table, as proposed by Russell. > > - Patch 4 implements automatic setting of TM, FIBRE and Backplane bits > from the list of supported linkmodes. > > - In Patch 5, we only read abilities from the PMA. Pause parameters > aren't built from the genphy_c45_pma_read_abilities, as it was done > in the previous iteration of the patch. We also amke use of > linkmode_mod_bit to make sure we mask-out unsupported modes. > > - In Patch 8, we manually check for the PMA device id to see if we have > to use a quirk when reading the 2.5G/5G Extended Abilities > > Maxime Chevallier (10): > net: phy: Update PHY linkmodes after config_init > net: phy: Mask-out non-compatible modes when setting the max-speed > net: phy: Move of_set_phy_eee_broken to phy-core.c > net: phy: Automatically fill the generic TP, FIBRE and Backplane modes > net: phy: Extract genphy_c45_pma_read_abilities from marvell10g > net: phy: Add generic support for 2.5GBaseT and 5GBaseT > net: phy: marvell10g: Add support for 2.5GBASET > net: phy: marvell10g: Force reading of 2.5/5G > net: mvpp2: Add 2.5GBaseT support > net: phy: marvell10g: add support for the 88x2110 PHY > > .../net/ethernet/marvell/mvpp2/mvpp2_main.c | 1 + > drivers/net/phy/marvell10g.c | 142 +++++------ > drivers/net/phy/phy-c45.c | 111 ++++++++ > drivers/net/phy/phy-core.c | 72 ++++++ > drivers/net/phy/phy_device.c | 237 +++++++++--------- > include/linux/linkmode.h | 6 + > include/linux/marvell_phy.h | 2 + > include/linux/phy.h | 3 + > include/uapi/linux/mdio.h | 16 ++ > 9 files changed, 405 insertions(+), 185 deletions(-) > Hi Maxime, Andrew and me are working on Aquantia PHY support and he handed over to me a patch series which includes parts of the first version of your series. Having said that I'm especially interested in your patches 5 and 6. Because your series is somewhat bigger and there are a few review comments, preparing the next round may take time. I'd propose that you extract generic patches being submission-ready and split the patch series into two. I think the following patches would be candidates for the first series: 2, 3, 5, 6 (provided they have no dependency on the other patches) Based on that both of us can go on with our work. Andrew, what do you think? Heiner
> I'd propose that you extract generic patches being submission-ready > and split the patch series into two. I think the following patches > would be candidates for the first series: 2, 3, 5, 6 > (provided they have no dependency on the other patches) > Based on that both of us can go on with our work. > > Andrew, what do you think? Yes, that would help. Heiner, can you also submit the .get_features patches soon. That is another important piece of the puzzle for both drivers. Thanks Andrew
On 09.02.2019 17:25, Andrew Lunn wrote: >> I'd propose that you extract generic patches being submission-ready >> and split the patch series into two. I think the following patches >> would be candidates for the first series: 2, 3, 5, 6 >> (provided they have no dependency on the other patches) >> Based on that both of us can go on with our work. >> >> Andrew, what do you think? > > Yes, that would help. > > Heiner, can you also submit the .get_features patches soon. That is > another important piece of the puzzle for both drivers. > Just submitted it few hours ago. https://patchwork.ozlabs.org/patch/1039237/ > Thanks > Andrew > Heiner
Hello Heiner, >Hi Maxime, > >Andrew and me are working on Aquantia PHY support and he handed over >to me a patch series which includes parts of the first version of your >series. Having said that I'm especially interested in your patches >5 and 6. Because your series is somewhat bigger and there are a few >review comments, preparing the next round may take time. > >I'd propose that you extract generic patches being submission-ready >and split the patch series into two. I think the following patches >would be candidates for the first series: 2, 3, 5, 6 >(provided they have no dependency on the other patches) >Based on that both of us can go on with our work. Sure, I'll sent that shortly. Thanks for the help, Maxime