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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251121120037.GA1117685@google.com>
Date: Fri, 21 Nov 2025 12:00:37 +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:

> On Thu, Nov 20, 2025 at 04:36:03PM +0000, Lee Jones wrote:
> > The canonical answer goes 3 ways: If you want to use the MFD API, move
> > the handling to drivers/mfd.
> 
> Wait, so now it's negotiable? What about "this device is not an MFD"
> from the other patch? Move it to another folder and suddenly it's an MFD?
> https://lore.kernel.org/netdev/20251120153622.p6sy77coa3de6srw@skbuf/

The "canonical answer" is the general answer, the one that applies to
everyone, not just your use-case.  I'm not (yet?) convinced that this is
an MFD, so at the moment, option one is not on the table for you.

> > 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!).
> 
> yay...
> 
> I don't need the code necessarily, just the overall idea if you remember it.

It was an extension to "simple-bus".  Perhaps "simple-mfd"?

Again, it might not work for you, but it's an avenue worth exploring.

> > Or if all else fails, you have to register the device the old
> > fashioned way with the platform_device_*() API.
> 
> Do you realize that by this, you are inviting me to waste time until the
> next reviewer rightfully asks, why didn't you use MFD, then I'll point
> them towards this discussion, but you didn't really answer?

This is still an abuse of the MFD API.  Used outside of the subsystem
for something that isn't an MFD.  I like the idea of not duplicating
code, but the fact remains that this is a hack.

Another more recent avenue you may explore is the Auxiliary Bus.

-- 
Lee Jones [李琼斯]

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ