Link modes representation in phylib

[Maxime Chevallier <maxime.chevallier@bootlin.com>]

Hello everyone,

I'm currently working on adding support for 2.5GBaseT on some Marvell
PHYs (the marvell10g family, including the 88X3310).

However, phylib doesn't quite support these modes yet. Its stores the
different supported and advertised modes in u32 fields, which can't
contain the relevant values for 2500BaseT mode (and all other modes that
come after the 31st one).

I'm refering to the "advertising", "lp_advertising" and "supported"
fields in struct phy_device [1] and also to the "features" in
struct phy_driver [2].

>From what I read, I think there are plans to switch these fields to a
newer representation, using the ETHTOOL_G/SLINKSETTINGS API for example.

>From my quick analysis, it seems this would require changing the drivers
in net/ethernet that still directly access the "phydev->supported"
fields (about 30 of them) to use phy_ethtool_ksettings_{g/s}et, and also
using another way to declare the "features" in phy_driver.

There are quite a lot of references to the "legacy" ways of representing
modes, this would be another step closer to switching the a newer
representation, but since this has an impact in a lot of places in 
net/, so I wanted to have your opinion on that point before attempting
anything.

So would you have any advice on how we should start supporting newer
modes in PHY drivers ?

Thanks,

Maxime

[1]
https://elixir.bootlin.com/linux/v4.18-rc1/source/include/linux/phy.h#L441

[2]
https://elixir.bootlin.com/linux/v4.18-rc1/source/include/linux/phy.h#L512

-- 
Maxime Chevallier, Bootlin (formerly Free Electrons)
Embedded Linux and kernel engineering
https://bootlin.com