All of lore.kernel.org
 help / color / mirror / Atom feed
From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
To: Andrew Lunn <andrew@lunn.ch>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Heiner Kallweit <hkallweit1@gmail.com>
Cc: netdev@vger.kernel.org
Subject: phylib's new dynamic feature detection seems too early
Date: Tue, 10 Dec 2019 17:15:36 +0000	[thread overview]
Message-ID: <20191210171536.GW25745@shell.armlinux.org.uk> (raw)

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

             reply	other threads:[~2019-12-10 17:15 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-10 17:15 Russell King - ARM Linux admin [this message]
2019-12-11 21:20 ` phylib's new dynamic feature detection seems too early Heiner Kallweit

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191210171536.GW25745@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=andrew@lunn.ch \
    --cc=f.fainelli@gmail.com \
    --cc=hkallweit1@gmail.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.