linux-kernel - Re: [PATCH net-next 08/15] net: dsa: sja1105: transition OF-based MDIO drivers to standalone

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: <20251120163603.GK661940@google.com>
Date: Thu, 20 Nov 2025 16:36:03 +0000
From: Lee Jones <lee@...nel.org>
To: Vladimir Oltean <vladimir.oltean@....com>
Cc: netdev@...r.kernel.org, Andrew Lunn <andrew@...n.ch>,
	Heiner Kallweit <hkallweit1@...il.com>,
	Russell King <linux@...linux.org.uk>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next 08/15] net: dsa: sja1105: transition OF-based
 MDIO drivers to standalone

On Thu, 20 Nov 2025, Vladimir Oltean wrote:

> Hi Lee,
> 
> Thank you for commenting on the patch!
> 
> On Thu, Nov 20, 2025 at 02:40:46PM +0000, Lee Jones wrote:
> > The MFD API is not to be {ab}used out side of drivers/mfd.
> 
> If mfd_add_devices() is not to be used outside of drivers/mfd, why
> export it to the global include/linux/mfd/core.h in the first place,
> rather than make the header available just to drivers/mfd?

That's a good question.

mfd_add_devices() has been exported since its inception nearly 20 years
ago.  But it wasn't {ab}used outside of the subsystem until 2011 when it
somehow found its way into the NVEC Staging driver and then into some
IIO driver in 2015, etc.  Since then other 8 instances have slipped
through the gaps without me noticing.  I'd love to remove the global
export, but something would need to be done about those 10 occurrences
before hand and I just don't have the time to invest in that right now.

> > Maybe of_platform_populate() will scratch your itch instead.
> 
> I did already explore of_platform_populate() on this thread which asked
> for advice (to which you were also copied):
> https://lore.kernel.org/lkml/20221222134844.lbzyx5hz7z5n763n@skbuf/
> 
>     It looks like of_platform_populate() would be an alternative option for
>     this task, but that doesn't live up to the task either. It will assume
>     that the addresses of the SoC children are in the CPU's address space
>     (IORESOURCE_MEM), and attempt to translate them. It simply doesn't have
>     the concept of IORESOURCE_REG. The MFD drivers which call
>     of_platform_populate() (simple-mfd-i2c.c) simply don't have unit
>     addresses for their children, and this is why address translation isn't
>     a problem for them.
> 
> I'm not trying to start an argument, but as you can see, I've been stuck
> on this problem for years, and I'm between a rock and a hard place.

I get that.  Equally, I'm not trying to be suborn, but those are the
rule's I've been attempting to stick to for the last decade and a bit to
prevent (minor) chaos.

The canonical answer goes 3 ways: If you want to use the MFD API, move
the handling to drivers/mfd.  If it's possible, use one of the
predetermined helpers like of_platform_populate() (and I think we
authored another one that worked around some of its issues, but I forget
where we put it!).  Or if all else fails, you have to register the
device the old fashioned way with the platform_device_*() API.

-- 
Lee Jones [李琼斯]