netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Michael Walle <michael@walle.cc>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	"David S . Miller" <davem@davemloft.net>,
	Xu Liang <lxu@maxlinear.com>,
	Alexandre Belloni <alexandre.belloni@bootlin.com>,
	Florian Fainelli <f.fainelli@gmail.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC net-next 4/5] net: phy: introduce is_c45_over_c22 flag
Date: Thu, 31 Mar 2022 14:04:43 +0100	[thread overview]
Message-ID: <YkWm67iM19V5C0Ln@shell.armlinux.org.uk> (raw)
In-Reply-To: <YkWZOEGwLcD6xYKu@lunn.ch>

On Thu, Mar 31, 2022 at 02:06:16PM +0200, Andrew Lunn wrote:
> On Thu, Mar 31, 2022 at 12:50:42PM +0100, Russell King (Oracle) wrote:
> > On Thu, Mar 24, 2022 at 07:55:28PM +0100, Andrew Lunn wrote:
> > > > The
> > > > > only valid case i can think of is for a very oddball PHY which has C45
> > > > > register space, but cannot actually do C45 transfers, and so C45 over
> > > > > C22 is the only option.
> > > > 
> > > > And how would you know that the PHY has the needed registers in c22
> > > > space? Or do we assume that every C45 PHY has these registers?
> > > 
> > > I think it is a reasonable assumption at the moment. We have around
> > > 170 MDIO bus masters in Linux. All but one can do C22.
> > 
> > I don't think that is correct. I'm aware of the Marvell XMDIO driver
> > that is C45 only, and also xgene's non-rgmii "xfi" variant which is
> > also C45 only. Note that the xfi variant doesn't reject C22 and makes
> > no distinction between a C22 and C45 access (so a C22 access to
> > phy_id = 0 reg = 0 hits C45 phy_id = 0 mmd 0 reg 0.
> > 
> > MDIO drivers are IMHO an utter mess and are in dire need of fixing...
> > and I'm coming to the conclusion that the bodge of passing both C22
> > and C45 accesses through the same read/write functions is a huge
> > mistake, one that is crying out for fixing to prevent more prolification
> > of this kind of mess.
> > 
> > Yes, it's a lot of work, but I think it needs to be done. Retrofitting
> > the MDIO drivers with checks etc sounds nice, but if we assume that
> > patches will continue to be applied to net-next with little review,
> > we have a losing battle - it would be better to have interfaces designed
> > to make this kind of mistake impossible.
> 
> Hi Russell
> 
> So what i think you are saying is change the mii_bus structure:
> 
> diff --git a/include/linux/phy.h b/include/linux/phy.h
> index 36ca2b5c2253..26322ee23867 100644
> --- a/include/linux/phy.h
> +++ b/include/linux/phy.h
> @@ -353,10 +353,15 @@ struct mii_bus {
>         const char *name;
>         char id[MII_BUS_ID_SIZE];
>         void *priv;
> -       /** @read: Perform a read transfer on the bus */
> -       int (*read)(struct mii_bus *bus, int addr, int regnum);
> -       /** @write: Perform a write transfer on the bus */
> -       int (*write)(struct mii_bus *bus, int addr, int regnum, u16 val);
> +       /** @read: Perform a C22 read transfer on the bus */
> +       int (*read_c22)(struct mii_bus *bus, int addr, int regnum);
> +       /** @write: Perform a C22 write transfer on the bus */
> +       int (*write_c22)(struct mii_bus *bus, int addr, int regnum, u16 val);
> +       /** @read: Perform a C45 read transfer on the bus */
> +       int (*read_c45)(struct mii_bus *bus, int addr, int devnum, int regnum);
> +       /** @write: Perform a C45 write transfer on the bus */
> +       int (*write_c45)(struct mii_bus *bus, int addr, int devnum,
> +                        int regnum, u16 val);
>         /** @reset: Perform a reset of the bus */
>         int (*reset)(struct mii_bus *bus);
> 
> This way we get a cleaner interface, and the compiler helping us
> finding drivers we miss during conversion?

Yes, and not only does it mean the compiler helps us find unconverted
drivers, it will also stop new drivers that use the old interfaces being
merged and most importantly it puts an end to the ongoing question about
which clause accesses are actually supported by a MDIO driver.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

  reply	other threads:[~2022-03-31 13:05 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-23 18:34 [PATCH RFC net-next 0/5] net: phy: C45-over-C22 access Michael Walle
2022-03-23 18:34 ` [PATCH RFC net-next 1/5] net: phy: mscc-miim: reject clause 45 register accesses Michael Walle
2022-03-23 19:27   ` Andrew Lunn
2022-03-23 20:14   ` Florian Fainelli
2022-03-23 18:34 ` [PATCH RFC net-next 2/5] net: phy: support indirect c45 access in get_phy_c45_ids() Michael Walle
2022-03-23 19:39   ` Andrew Lunn
2022-03-23 22:14     ` Michael Walle
2022-03-30 16:18       ` Russell King (Oracle)
2022-03-31  8:28         ` Michael Walle
2022-03-24 14:28     ` Michael Walle
2022-03-24 15:09       ` Andrew Lunn
2022-03-23 18:34 ` [PATCH RFC net-next 3/5] net: phy: mscc-miim: add probe_capabilities Michael Walle
2022-03-23 20:14   ` Florian Fainelli
2022-03-23 18:34 ` [PATCH RFC net-next 4/5] net: phy: introduce is_c45_over_c22 flag Michael Walle
2022-03-23 20:07   ` Andrew Lunn
2022-03-23 22:38     ` Michael Walle
2022-03-24  0:41       ` Andrew Lunn
2022-03-24 16:03         ` Michael Walle
2022-03-24 16:23           ` Andrew Lunn
2022-03-24 17:18             ` Michael Walle
2022-03-24 18:55               ` Andrew Lunn
2022-03-31 11:50                 ` Russell King (Oracle)
2022-03-31 12:06                   ` Andrew Lunn
2022-03-31 13:04                     ` Russell King (Oracle) [this message]
2022-03-31 11:44               ` Russell King (Oracle)
2022-03-31 11:31         ` Russell King (Oracle)
2022-03-23 18:34 ` [PATCH RFC net-next 5/5] net: phylink: handle the new is_c45_over_c22 property Michael Walle
2022-03-23 20:30 ` [PATCH RFC net-next 0/5] net: phy: C45-over-C22 access Andrew Lunn
2022-03-23 23:01   ` Michael Walle

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=YkWm67iM19V5C0Ln@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=alexandre.belloni@bootlin.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=hkallweit1@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lxu@maxlinear.com \
    --cc=michael@walle.cc \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    /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).