Thread (42 messages) 42 messages, 7 authors, 29d ago

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

From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date: 2026-03-23 22:27:55
Also in: driver-core, linux-fpga, linux-leds, linux-phy, linux-spi, lkml

On Mon, Mar 23, 2026 at 11:11:58PM +0100, Andrew Lunn wrote:
On Mon, Mar 23, 2026 at 02:41:03PM -0700, Dmitry Torokhov wrote:
quoted
On Mon, Mar 23, 2026 at 09:36:07PM +0000, Mark Brown wrote:
quoted
On Mon, Mar 23, 2026 at 09:01:47PM +0100, Andrew Lunn wrote:
quoted
How do you handle deprecated OF properties? This is a problem i've run
into before. A developer needs an ACPI binding, so they blindly
convert from of_ to device_ without engaging brain. As a result, they
bring all the deprecated OF properties we want to die into the brand
new ACPI bindings.
Honestly that one hasn't really come up much for me - not too many
deprecated properties.
Given that we position properties as an ABI even if they are deprecated
we supposed to handle them forever. Newer properties usually offer
benefits over old ones and that is how users get moved over.
~/linux/Documentation/devicetree/bindings/net$ grep -r deprecated * | wc
     75     361    4195

So networking has ~ 75 of them.

Within the OF world, they are ABI and we need to keep them. But we
don't want them in ACPI or any other firmware. Any code looking for
properties needs to know what is underneath so it can decide if it
should look for the deprecated, OF only property, or not.
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);

You do not need much more than that... Checking node type only
complicates the code, especially when a device can be used on both ACPI
and DT systems.

Thanks.

-- 
Dmitry
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help