netdev - phylib's new dynamic feature detection seems too early

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:   Tue, 10 Dec 2019 17:15:36 +0000
From:   Russell King - ARM Linux admin <linux@...linux.org.uk>
To:     Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>,
        Heiner Kallweit <hkallweit1@...il.com>
Cc:     netdev@...r.kernel.org
Subject: phylib's new dynamic feature detection seems too early

Hi,

Back in dcdecdcfe1fc ("net: phy: switch drivers to use dynamic feature
detection"), Heiner switched a bunch of PHYs over to using his
wonderful new idea of reading the PHY capabilities from the registers.
However, this is flawed.

The features are read from the PHY shortly after the PHY driver is
bound to the device, while the PHY is in its default pin-strapped
defined mode. PHYs such as the 88E1111 set their capabilities according
to the pin-strapped host interface mode.

If the 88E1111 is pin-strapped for a 1000base-X host interface, then it
indicates that it is not capable of 100M or 10M modes - which is
entirely sensible.

However, the SFP support will switch the PHY into SGMII mode, where the
PHY will support 100M and 10M modes. Indeed, reading the PHY registers
using mii-diag after initialisation reports that the PHY supports these
speeds.

This switch happens in the Marvell PHY driver when the config_init()
method is called, via phy_init_hw() and phy_attach_direct() - which
is where the MAC driver configures the PHY for its requested interface
mode.

Therefore, the features dynamically read from the PHY are entirely
meaningless, until the PHY interface mode has been properly set.

This means that SFP modules, such as Champion One 1000SFPT and a
multitude of others which default to a 1000base-X interface end up
only advertising 1000baseT despite being switched to SGMII mode and
actually supporting 100M and 10M speeds - and that can't be changed
via ethtool as the support mask doesn't allow the other speeds.

Thoughts how to get around this?

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up