netdev - Link modes representation in phylib

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 18 Jun 2018 17:02:24 +0200
From:   Maxime Chevallier <maxime.chevallier@...tlin.com>
To:     davem@...emloft.net,
        Russell King - ARM Linux <linux@...linux.org.uk>,
        Florian Fainelli <f.fainelli@...il.com>,
        Andrew Lunn <andrew@...n.ch>, netdev <netdev@...r.kernel.org>,
        Antoine Tenart <antoine.tenart@...tlin.com>,
        "thomas.petazzoni@...tlin.com" <thomas.petazzoni@...tlin.com>,
        Gregory CLEMENT <gregory.clement@...tlin.com>,
        Miquel Raynal <miquel.raynal@...tlin.com>
Subject: Link modes representation in phylib

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