Re: [PATCH 04/10] regulator: of: switch to using class_find_device_by_fwnode()

Mark Brown <[email protected]> Mon, 23 Mar 2026 19:58:14 +0000

Newsgroups	org.kernel.vger.linux-fpga,dev.linux.lists.driver-core,org.infradead.lists.linux-phy,org.kernel.vger.linux-kernel,org.kernel.vger.linux-leds,org.kernel.vger.linux-spi,org.kernel.vger.netdev
Message-ID	<[email protected]>

On Mon, Mar 23, 2026 at 12:41:59PM -0700, Dmitry Torokhov wrote:
> On Mon, Mar 23, 2026 at 07:05:13PM +0000, Mark Brown wrote:

> > I think this is a worrying idea for core code like this, we have
> > specific firmware bindings for specific firmware interfaces with the
> > different interfaces having very different ideas of how things should be
> > modelled.  The chances that firmware agnostic code is going to do the
> > right thing seem low, and encouraging the use of generic APIs that might
> > happen to run OK raises the risk that we'll get firmware vendors relying
> > on them and leaving us with a conceptual mishmash to sort through.

> Firmware vendors can introduce incompatible DT bindings and have them in
> their devices too and we have to deal with that... 

The case that's worrying me is mixing the ACPI and DT design models in
one system, and especially having that happen to actually work without
modification purely by luck rather than by design.

> I think if this pushes closer ACPI and OF schemas for at least some
> subsystems closer to each other it would not be a bad thing.

I think we shouldn't be encouraging people to just throw random stuff at
the wall and see if it happens to run OK with whatever OS they tried
booting.  The differences between ACPI and DT in areas like the
regulator bindings are fundamental conceptual ones.  There's some areas
where things are closer and it winds up being fine actually, especially
for leaf devices, but there's others where that's less likely.

signature.asc (application/pgp-signature, 488 B)