From: Heiner Kallweit <hkallweit1@gmail.com>
To: Russell King - ARM Linux admin <linux@armlinux.org.uk>,
Andrew Lunn <andrew@lunn.ch>,
Florian Fainelli <f.fainelli@gmail.com>
Cc: netdev@vger.kernel.org
Subject: Re: phylib's new dynamic feature detection seems too early
Date: Wed, 11 Dec 2019 22:20:33 +0100 [thread overview]
Message-ID: <e6e063bd-e6da-1b23-b012-e10f7415ab2b@gmail.com> (raw)
In-Reply-To: <20191210171536.GW25745@shell.armlinux.org.uk>
On 10.12.2019 18:15, Russell King - ARM Linux admin wrote:
> 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?
>
Before reading PHY capabilities from the registers the capabilities
were completely static, I don't think this was better.
The capabilities read in phy_probe() are correct for the default
interface mode. And for all PHY drivers not implementing
config_init() we have to read the capabilities in phy_probe().
In case the capabilities can change in config_init() a first thought
would be to clear supported/advertised and re-read the capabilities
at the end of config_init().
Heiner
prev parent reply other threads:[~2019-12-11 21:20 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-10 17:15 phylib's new dynamic feature detection seems too early Russell King - ARM Linux admin
2019-12-11 21:20 ` Heiner Kallweit [this message]
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=e6e063bd-e6da-1b23-b012-e10f7415ab2b@gmail.com \
--to=hkallweit1@gmail.com \
--cc=andrew@lunn.ch \
--cc=f.fainelli@gmail.com \
--cc=linux@armlinux.org.uk \
--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.