From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
To: Andrew Lunn <andrew@lunn.ch>, Heiner Kallweit <hkallweit1@gmail.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>,
Jeremy Linton <jeremy.linton@arm.com>,
netdev@vger.kernel.org
Subject: [PATCH RFC v2 0/9] Clause 45 PHY probing cleanups
Date: Wed, 27 May 2020 11:33:18 +0100 [thread overview]
Message-ID: <20200527103318.GK1551@shell.armlinux.org.uk> (raw)
Hi,
This is version 2 of my proposal to expand our Clause 45 PHY probing.
This series does not change the functionality beyond probing further
MMDs.
The first four patches clean up get_phy_device() and called functions,
updating the kernel doc, adding information about the various error
return values.
This is not against net-next nor net trees, but against my own private
tree, but I'm posting it to serve as an illustration of what I think
should be done - I knocked this up this morning.
I haven't tested the new changes in version 2 yet beyond compile
testing.
Given the proximity of the merge window, this *isn't* code I'd like to
see merged into net-next - it's way too risky at this point. So, we
have time to consider our options.
If we want to start scanning for Clause 45 PHYs like we do for Clause
22 PHYs, we definitely need to have indications from the MDIO drivers
that they support Clause 45 accesses, or all MDIO drivers audited to
add the necessary rejection; many of them do not explicitly reject a
request to perform Clause 45 accesses, and will just try and fit the
unmasked register address into their registers, potentially setting
invalid bits when writing their registers.
Changes from v2:
- Further cleanups to get_phy_c45_ids(), get_phy_c22_id() and
get_phy_device(), with kerneldoc updates to better describe what
is going on, and what the error return codes signify.
- Only read status register 2 to detect device presence for the
two vendor MMDs which we know are a potential problem on 88x3310
PHYs. We can expand to also check MMDs 1 through 6 if necessary,
but that would be a behaviour change beyond what this series is
trying to do.
Unaddressed issues:
- Reading zero from PHY ID registers - OUI 00:00:00 is allocated to
Xerox Corporation, but it's unlikely that there is a PHY out there
validly using this OUI. However, I believe that we do know that
there are PHYs with zero PHY ID registers (in DSA switches, Andrew?)
- mmds_present - I have a patch on top of this which clears the vendor
MMDs if the devices-present field in status register 2 indicates
not-present. We may wish to do this for MMDs 1 through 6 as well
which have status register 2, but that comes with some risk.
Discussion points:
- drivers/net/phy is becoming quite large, do we want to split it
into separate subdirectories for PHY drivers, MDIO drivers, and
core code?
- I have a patch that splits the "genphy" clause 22 code like I did
with the clause 45 code, which will need refreshing before I
submit - do my fellow phylib maintainers think that's a good move?
drivers/net/phy/phy-c45.c | 4 +-
drivers/net/phy/phy_device.c | 159 ++++++++++++++++++++++++++++---------------
drivers/net/phy/phylink.c | 8 +--
include/linux/phy.h | 8 ++-
4 files changed, 117 insertions(+), 62 deletions(-)
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up
next reply other threads:[~2020-05-27 10:33 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-27 10:33 Russell King - ARM Linux admin [this message]
2020-05-27 10:33 ` [PATCH RFC v2 1/9] net: phy: clean up cortina workaround Russell King
2020-05-27 10:33 ` [PATCH RFC v2 2/9] net: phy: clean up PHY ID reading Russell King
2020-05-27 16:31 ` Florian Fainelli
2020-05-27 10:33 ` [PATCH RFC v2 3/9] net: phy: clean up get_phy_c45_ids() failure handling Russell King
2020-05-27 16:32 ` Florian Fainelli
2020-05-27 10:34 ` [PATCH RFC v2 4/9] net: phy: clean up get_phy_c22_id() invalid ID handling Russell King
2020-05-27 16:33 ` Florian Fainelli
2020-05-27 10:34 ` [PATCH RFC v2 5/9] net: phy: reword get_phy_device() kerneldoc Russell King
2020-05-27 16:33 ` Florian Fainelli
2020-05-27 10:34 ` [PATCH RFC v2 6/9] net: phy: add support for probing MMDs >= 8 for devices-in-package Russell King
2020-05-27 16:34 ` Florian Fainelli
2020-06-10 16:16 ` Calvin Johnson
2020-06-10 16:34 ` Russell King - ARM Linux admin
2020-06-11 6:01 ` Calvin Johnson
2020-05-27 10:34 ` [PATCH RFC v2 7/9] net: phy: set devices_in_package only after validation Russell King
2020-05-27 16:35 ` Florian Fainelli
2020-05-27 10:34 ` [PATCH RFC v2 8/9] net: phy: split devices_in_package Russell King
2020-05-27 16:36 ` Florian Fainelli
2020-05-27 10:34 ` [PATCH RFC v2 9/9] net: phy: read MMD ID from all present MMDs Russell King
2020-05-27 16:40 ` Florian Fainelli
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=20200527103318.GK1551@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=andrew@lunn.ch \
--cc=f.fainelli@gmail.com \
--cc=hkallweit1@gmail.com \
--cc=jeremy.linton@arm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).