linux-kernel - Re: [net-next PATCH v12 07/13] net: mdio: regmap: add support for multiple valid addr

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Z9Ss0qrxCcEbyJY7@shell.armlinux.org.uk>
Date: Fri, 14 Mar 2025 22:25:22 +0000
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Christian Marangi <ansuelsmth@...il.com>
Cc: Andrew Lunn <andrew@...n.ch>, Lee Jones <lee@...nel.org>,
	Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Andrew Lunn <andrew+netdev@...n.ch>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Vladimir Oltean <olteanv@...il.com>,
	Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
	Heiner Kallweit <hkallweit1@...il.com>,
	Maxime Chevallier <maxime.chevallier@...tlin.com>,
	Matthias Brugger <matthias.bgg@...il.com>,
	AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	linux-mediatek@...ts.infradead.org, netdev@...r.kernel.org,
	upstream@...oha.com
Subject: Re: [net-next PATCH v12 07/13] net: mdio: regmap: add support for
 multiple valid addr

On Fri, Mar 14, 2025 at 10:19:29PM +0100, Christian Marangi wrote:
> On Fri, Mar 14, 2025 at 09:01:56PM +0000, Russell King (Oracle) wrote:
> > I'd prefer we didn't bring that abomination back. The detail about how
> > things are stored in regmap should be internal within regmap, and I
> > think it would be better to have an API presented that takes sensible
> > parameters, rather than something that's been encoded.
> 
> Well problem is that regmap_write and regmap_read will take max 2 value
> at the very end (reg and value) so it's really a matter of making the
> encoding part internal but encoding it can't be skipped.
> 
> You are suggesting to introduce additional API like
> 
> mdio_regmap_write(regmap, phy, addr, val);
> mdio_mmd_regmap_write(regmap, phy, mmd, addr, val);
> 
> And the encoding is done internally?

Yes, because littering drivers with the details of the conversion is
unreasonable.

> My concern is the decoding part from the .write/read_bits regmap OPs.
> I guess for that also some helper should be exposed (to keep the
> decoding/encoding internal to the driver and not expose the
> _abomination_)

Sadly, I don't think that's something we can get away from, but we
should make it _easy_ for people to get it right.

>From what I remember from the days of shoe-horning C45 into the C22
MDIO API, encoding and/or decoding addresses was buggy because people
would use the wrong encoders and decoders.

For example, we had MDIO drivers using mdio_phy_id_is_c45() to test
whether the access being requested was C45 - mdio_phy_id_is_c45() is
for the _userspace_ MII API encoding (struct mii_ioctl_data), not the
kernel space. Kernel space used:

-#define MII_ADDR_C45 (1<<30)
-#define MII_DEVADDR_C45_SHIFT  16
-#define MII_REGADDR_C45_MASK   GENMASK(15, 0)

to encode into the register number argument vs the userspace encoding
into the phy_id member of struct mii_ioctl_data:

#define MDIO_PHY_ID_C45                 0x8000
#define MDIO_PHY_ID_PRTAD               0x03e0
#define MDIO_PHY_ID_DEVAD               0x001f

which is what the mdio_phy_id_*() accessors are using. The two
approaches are incompatible, and using the userspace one in a MDIO
driver wasn't going to work correctly - but people did it.

This is one of the reasons I hated the old MDIO API, and why we now
have separate C22 and C45 interfaces in the driver code.

This is exactly why I don't like reintroducing a new set of "massage
the package, mmd and address into some single integer representation"
and "decode a single integer into their respective parts" - we've
been here before, it's lead to problems because driver authors can't
grasp what the right approach is, and it results in bugs.

Given the history here, my personal opinion would be... if regmap can't
cope with MDIO devices having a three-part address without requiring
callers to flatten it first, and then have various regmap drivers
unflatten it, then regmap is unsuitable to be used with MDIO and ought
not be used.

So, this encoding/decoding is a problem that should be solved entirely
within regmap, and not spread out into users of regmap and drivers
behind regmap. Anything else is, IMHO, insane.

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