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

[Andrew Lunn]

On Mon, Mar 23, 2026 at 03:48:42PM -0700, Dmitry Torokhov wrote:
> On Mon, Mar 23, 2026 at 11:39:03PM +0100, Andrew Lunn wrote:
> > > If there is a deprecated property you can do:
> > > 
> > > 	error = device_property_read_u32(dev, "prop", &val);
> > > 	if (error == -ENOENT)
> > > 		error = device_property_read_u32(dev, "deprecated-prop", &val);
> > 
> > It is not as simple as that. There are a lot of optional
> > properties. Say "prop" is optional? And not present. So -ENOENT. We
> > then look for this deprecated property. That should not happen.
> 
> Why? That is exactly what you want: you favor new one if it is present
> and fall back to deprecated one if it is absent. And then you decide
> whether to continue or abort.

The old property is only valid in DT, where it is deprecated, but
still valid. It should never appear in any other newer firmware
bindings.

> If you only have of_property_read_u32() then it will not stand out. If
> you advocate of using device_property_read_u32() normally but
> of_property_read_u32() for deprecated only - that is a possibility, but
> I do not know if anyone does this.

For the subsystems i've dealt with, when somebody proposes a patch
adding an ACPI binding, and they do an of_ to device_ conversion
without engaging brain, i point out the issues, they should not be
adding deprecated properties to a brand new binding, and they go away
and never come back. And so the code remains OF only. Which is fine,
nobody does networking devices using ACPI.

       Andrew