Re: [PATCH 04/10] regulator: of: switch to using class_find_device_by_fwnode()
Dmitry Torokhov <[email protected]> Mon, 23 Mar 2026 12:41:59 -0700
| 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 07:05:13PM +0000, Mark Brown wrote: > On Mon, Mar 23, 2026 at 11:28:27AM -0700, Dmitry Torokhov wrote: > > On Mon, Mar 23, 2026 at 02:00:43PM +0000, Mark Brown wrote: > > > > The regulator API is very deliberately specifically using the OF APIs, > > > not the ACPI APIs, since ACPI really doesn't want to model regulators. > > > For now? We also have software nodes and maybe we come up with something > > else in the future... > > > I think we should use firmware-agnostic APIs as much as possible, and > > only use OF- or ACPI-specific ones when there is no generic equivalent. > > This makes the code most flexible. > > 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. > > Software nodes are already a bit of a concern here TBH. Firmware vendors can introduce incompatible DT bindings and have them in their devices too and we have to deal with that... 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. Thanks. -- Dmitry