[PATCH 00/10] Remove class_find_device_by_of_node in favor of finding by firmware node

[PATCH 00/10] Remove class_find_device_by_of_node in favor of finding by firmware node

[Dmitry Torokhov]

Firmware nodes are generalization of OF device nodes and generic APIs
should offer only fwnode variants instead of providing firmware-specific
handlers.

This series switches all users of class_find_device_by_of_node() to
class_find_device_by_fwnode() and removes the OF variant.

I believe this can be applied through individual subsystems and then the
last patch can go into the driver core.

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
Dmitry Torokhov (10):
      net: wan: framer: switch to using class_find_device_by_fwnode()
      phy: core: switch to using class_find_device_by_fwnode()
      spi: switch to using class_find_device_by_fwnode()
      regulator: of: switch to using class_find_device_by_fwnode()
      leds: led-class: switch to using class_find_device_by_fwnode()
      mux: switch to using class_find_device_by_fwnode()
      net: phy: switch to using class_find_device_by_fwnode()
      fpga: bridge: switch to using class_find_device_by_fwnode()
      fpga: manager: switch to using class_find_device_by_fwnode()
      driver core: class: remove class_find_device_by_of_node()

 drivers/fpga/fpga-bridge.c           |  4 +++-
 drivers/fpga/fpga-mgr.c              |  3 ++-
 drivers/leds/led-class.c             |  2 +-
 drivers/mux/core.c                   |  2 +-
 drivers/net/phy/mdio_bus_provider.c  |  4 +++-
 drivers/net/wan/framer/framer-core.c |  2 +-
 drivers/phy/phy-core.c               |  3 ++-
 drivers/regulator/of_regulator.c     |  2 +-
 drivers/spi/spi.c                    |  6 ++++--
 include/linux/device/class.h         | 12 ------------
 10 files changed, 18 insertions(+), 22 deletions(-)
---
base-commit: 785f0eb2f85decbe7c1ef9ae922931f0194ffc2e
change-id: 20260220-remove-device-find-by-of-node-077784fa109c

Thanks.

-- 
Dmitry

[PATCH net-next 01/10] net: wan: framer: switch to using class_find_device_by_fwnode()

[Dmitry Torokhov]

In preparation to class_find_device_by_of_node() going away switch to
using class_find_device_by_fwnode().

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
 drivers/net/wan/framer/framer-core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wan/framer/framer-core.c b/drivers/net/wan/framer/framer-core.c
index d779b03a9e1b..77ef1bfd476c 100644
--- a/drivers/net/wan/framer/framer-core.c
+++ b/drivers/net/wan/framer/framer-core.c
@@ -745,7 +745,7 @@ struct framer *framer_provider_simple_of_xlate(struct device *dev,
 {
 	struct device *target_dev;
 
-	target_dev = class_find_device_by_of_node(&framer_class, args->np);
+	target_dev = class_find_device_by_fwnode(&framer_class, of_fwnode_handle(args->np));
 	if (!target_dev)
 		return ERR_PTR(-ENODEV);
 

-- 
2.53.0.959.g497ff81fa9-goog

[PATCH 02/10] phy: core: switch to using class_find_device_by_fwnode()

[Dmitry Torokhov]

In preparation to class_find_device_by_of_node() going away switch to
using class_find_device_by_fwnode().

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
 drivers/phy/phy-core.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index 21aaf2f76e53..57bce6b63a31 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -761,7 +761,8 @@ struct phy *of_phy_simple_xlate(struct device *dev,
 {
 	struct device *target_dev;
 
-	target_dev = class_find_device_by_of_node(&phy_class, args->np);
+	target_dev = class_find_device_by_fwnode(&phy_class,
+						 of_fwnode_handle(args->np));
 	if (!target_dev)
 		return ERR_PTR(-ENODEV);
 

-- 
2.53.0.959.g497ff81fa9-goog

[PATCH 03/10] spi: switch to using class_find_device_by_fwnode()

[Dmitry Torokhov]

In preparation to class_find_device_by_of_node() going away switch to
using class_find_device_by_fwnode().

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
 drivers/spi/spi.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index bf1df365f795..071a9ffdb59d 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -21,6 +21,7 @@
 #include <linux/kthread.h>
 #include <linux/mod_devicetable.h>
 #include <linux/mutex.h>
+#include <linux/of.h>
 #include <linux/of_device.h>
 #include <linux/of_irq.h>
 #include <linux/percpu.h>
@@ -4948,11 +4949,12 @@ EXPORT_SYMBOL_GPL(spi_write_then_read);
 /* The spi controllers are not using spi_bus, so we find it with another way */
 struct spi_controller *of_find_spi_controller_by_node(struct device_node *node)
 {
+	struct fwnode_handle *fwnode = of_fwnode_handle(node);
 	struct device *dev;
 
-	dev = class_find_device_by_of_node(&spi_controller_class, node);
+	dev = class_find_device_by_fwnode(&spi_controller_class, fwnode);
 	if (!dev && IS_ENABLED(CONFIG_SPI_SLAVE))
-		dev = class_find_device_by_of_node(&spi_target_class, node);
+		dev = class_find_device_by_fwnode(&spi_target_class, fwnode);
 	if (!dev)
 		return NULL;
 

-- 
2.53.0.959.g497ff81fa9-goog

Re: [PATCH 03/10] spi: switch to using class_find_device_by_fwnode()

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 219 bytes --]

On Sun, Mar 22, 2026 at 06:54:21PM -0700, Dmitry Torokhov wrote:
> In preparation to class_find_device_by_of_node() going away switch to
> using class_find_device_by_fwnode().

Acked-by: Mark Brown <broonie@kernel.org>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 03/10] spi: switch to using class_find_device_by_fwnode()

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1014 bytes --]

On Sun, Mar 22, 2026 at 06:54:21PM -0700, Dmitry Torokhov wrote:
> In preparation to class_find_device_by_of_node() going away switch to
> using class_find_device_by_fwnode().

>  struct spi_controller *of_find_spi_controller_by_node(struct device_node *node)
>  {
> +	struct fwnode_handle *fwnode = of_fwnode_handle(node);
>  	struct device *dev;
>  
> -	dev = class_find_device_by_of_node(&spi_controller_class, node);
> +	dev = class_find_device_by_fwnode(&spi_controller_class, fwnode);
>  	if (!dev && IS_ENABLED(CONFIG_SPI_SLAVE))
> -		dev = class_find_device_by_of_node(&spi_target_class, node);
> +		dev = class_find_device_by_fwnode(&spi_target_class, fwnode);
>  	if (!dev)
>  		return NULL;

Actually, no - this just looks weird.  We're in the middle of an OF
specific function but we're having to jump up to fwnode for no apparent
reason.  If we actually decide to get rid of the OF specific function
then I guess but I'm really not convinced this is an improvement in
isolation.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 03/10] spi: switch to using class_find_device_by_fwnode()

[Dmitry Torokhov]

On Mon, Mar 23, 2026 at 05:16:04PM +0000, Mark Brown wrote:
> On Sun, Mar 22, 2026 at 06:54:21PM -0700, Dmitry Torokhov wrote:
> > In preparation to class_find_device_by_of_node() going away switch to
> > using class_find_device_by_fwnode().
> 
> >  struct spi_controller *of_find_spi_controller_by_node(struct device_node *node)
> >  {
> > +	struct fwnode_handle *fwnode = of_fwnode_handle(node);
> >  	struct device *dev;
> >  
> > -	dev = class_find_device_by_of_node(&spi_controller_class, node);
> > +	dev = class_find_device_by_fwnode(&spi_controller_class, fwnode);
> >  	if (!dev && IS_ENABLED(CONFIG_SPI_SLAVE))
> > -		dev = class_find_device_by_of_node(&spi_target_class, node);
> > +		dev = class_find_device_by_fwnode(&spi_target_class, fwnode);
> >  	if (!dev)
> >  		return NULL;
> 
> Actually, no - this just looks weird.  We're in the middle of an OF
> specific function but we're having to jump up to fwnode for no apparent
> reason.  If we actually decide to get rid of the OF specific function
> then I guess but I'm really not convinced this is an improvement in
> isolation.

Yes, I want to remove OF-specific APIs from the driver core. I also have
drafts for bus_find_device_by_fwnode and others.

I can make a followup series introducing spi_find_controller_by_fwnode()
and removing this OF-specific variant.

Thanks.

-- 
Dmitry

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

[Dmitry Torokhov]

In preparation to class_find_device_by_of_node() going away switch to
using class_find_device_by_fwnode().

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
 drivers/regulator/of_regulator.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/regulator/of_regulator.c b/drivers/regulator/of_regulator.c
index c0cc6cc0afd8..43ec0845c940 100644
--- a/drivers/regulator/of_regulator.c
+++ b/drivers/regulator/of_regulator.c
@@ -637,7 +637,7 @@ static struct regulator_dev *of_find_regulator_by_node(struct device_node *np)
 {
 	struct device *dev;
 
-	dev = class_find_device_by_of_node(&regulator_class, np);
+	dev = class_find_device_by_fwnode(&regulator_class, of_fwnode_handle(np));
 
 	return dev ? dev_to_rdev(dev) : NULL;
 }

-- 
2.53.0.959.g497ff81fa9-goog

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 500 bytes --]

On Sun, Mar 22, 2026 at 06:54:22PM -0700, Dmitry Torokhov wrote:
> In preparation to class_find_device_by_of_node() going away switch to
> using class_find_device_by_fwnode().

>  	struct device *dev;
>  
> -	dev = class_find_device_by_of_node(&regulator_class, np);
> +	dev = class_find_device_by_fwnode(&regulator_class, of_fwnode_handle(np));

The regulator API is very deliberately specifically using the OF APIs,
not the ACPI APIs, since ACPI really doesn't want to model regulators.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Dmitry Torokhov]

On Mon, Mar 23, 2026 at 02:00:43PM +0000, Mark Brown wrote:
> On Sun, Mar 22, 2026 at 06:54:22PM -0700, Dmitry Torokhov wrote:
> > In preparation to class_find_device_by_of_node() going away switch to
> > using class_find_device_by_fwnode().
> 
> >  	struct device *dev;
> >  
> > -	dev = class_find_device_by_of_node(&regulator_class, np);
> > +	dev = class_find_device_by_fwnode(&regulator_class, of_fwnode_handle(np));
> 
> 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.

Anyway, I am not proposing to change all of the regulator code, just
clean up driver core APIs.

Thanks.

-- 
Dmitry

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1110 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Dmitry Torokhov]

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

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1545 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Dmitry Torokhov]

On Mon, Mar 23, 2026 at 07:58:14PM +0000, Mark Brown wrote:
> 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.

Maybe we should just have explicit checks with nice comments at the
beginning of the schema parsing stating that this schema is
intentionally restricted to OF (or ACPI) in cases where we ave distinct
schemas? This way it is explicit that it is a thought out decision and
not simply a legacy artefact.

I think we want to hanel software nodes because they do not
form their own schemas, they follow the existing ones (DT usually).

-- 
Dmitry

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

[Andrew Lunn]

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.

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.

A agree with Mark here. OF != ACPI, and anything which makes it appear
they are the same is just going to lead developers down the wrong path
and increase Maintainers work pointing out all the problems.

    Andrew

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 456 bytes --]

On Mon, Mar 23, 2026 at 09:01:47PM +0100, Andrew Lunn wrote:

> 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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Dmitry Torokhov]

On Mon, Mar 23, 2026 at 09:36:07PM +0000, Mark Brown wrote:
> On Mon, Mar 23, 2026 at 09:01:47PM +0100, Andrew Lunn wrote:
> 
> > 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.

Thanks.

-- 
Dmitry

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

[Andrew Lunn]

On Mon, Mar 23, 2026 at 02:41:03PM -0700, Dmitry Torokhov wrote:
> On Mon, Mar 23, 2026 at 09:36:07PM +0000, Mark Brown wrote:
> > On Mon, Mar 23, 2026 at 09:01:47PM +0100, Andrew Lunn wrote:
> > 
> > > 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.

     Andrew

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

[Dmitry Torokhov]

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:
> > On Mon, Mar 23, 2026 at 09:36:07PM +0000, Mark Brown wrote:
> > > On Mon, Mar 23, 2026 at 09:01:47PM +0100, Andrew Lunn wrote:
> > > 
> > > > 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

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

[Andrew Lunn]

> 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.

Using of_property_read_u32(np, "deprecated-prop", &val) actually makes
it stand out, it is special somehow, which is good, because it is
special.

   Andrew

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

[Dmitry Torokhov]

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.

Or you are saying that new property is optional but old one was
mandatory? Not sure...

> 
> Using of_property_read_u32(np, "deprecated-prop", &val) actually makes
> it stand out, it is special somehow, which is good, because it is
> special.

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.

Thanks.

-- 
Dmitry

Re: [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

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

[Russell King (Oracle)]

On Mon, Mar 23, 2026 at 09:01:47PM +0100, Andrew Lunn wrote:
> 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.
> 
> 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.
> 
> A agree with Mark here. OF != ACPI, and anything which makes it appear
> they are the same is just going to lead developers down the wrong path
> and increase Maintainers work pointing out all the problems.

That's three who agree.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

[PATCH 05/10] leds: led-class: switch to using class_find_device_by_fwnode()

[Dmitry Torokhov]

In preparation to class_find_device_by_of_node() going away switch to
using class_find_device_by_fwnode().

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
 drivers/leds/led-class.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
index d34a19453560..8d7ec9ccb173 100644
--- a/drivers/leds/led-class.c
+++ b/drivers/leds/led-class.c
@@ -273,7 +273,7 @@ static struct led_classdev *of_led_get(struct device_node *np, int index,
 	if (!led_node)
 		return ERR_PTR(-ENOENT);
 
-	led_dev = class_find_device_by_of_node(&leds_class, led_node);
+	led_dev = class_find_device_by_fwnode(&leds_class, of_fwnode_handle(led_node));
 	of_node_put(led_node);
 
 	return led_module_get(led_dev);

-- 
2.53.0.959.g497ff81fa9-goog

[PATCH 06/10] mux: switch to using class_find_device_by_fwnode()

[Dmitry Torokhov]

In preparation to class_find_device_by_of_node() going away switch to
using class_find_device_by_fwnode().

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
 drivers/mux/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mux/core.c b/drivers/mux/core.c
index 23538de2c91b..774d4cc67cc1 100644
--- a/drivers/mux/core.c
+++ b/drivers/mux/core.c
@@ -521,7 +521,7 @@ static struct mux_chip *of_find_mux_chip_by_node(struct device_node *np)
 {
 	struct device *dev;
 
-	dev = class_find_device_by_of_node(&mux_class, np);
+	dev = class_find_device_by_fwnode(&mux_class, of_fwnode_handle(np));
 
 	return dev ? to_mux_chip(dev) : NULL;
 }

-- 
2.53.0.959.g497ff81fa9-goog

[PATCH net-next 07/10] net: phy: switch to using class_find_device_by_fwnode()

[Dmitry Torokhov]

In preparation to class_find_device_by_of_node() going away switch to
using class_find_device_by_fwnode().

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
 drivers/net/phy/mdio_bus_provider.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/phy/mdio_bus_provider.c b/drivers/net/phy/mdio_bus_provider.c
index 041576eba47a..ed3cd9a37c67 100644
--- a/drivers/net/phy/mdio_bus_provider.c
+++ b/drivers/net/phy/mdio_bus_provider.c
@@ -21,6 +21,7 @@
 #include <linux/mii.h>
 #include <linux/mm.h>
 #include <linux/netdevice.h>
+#include <linux/of.h>
 #include <linux/of_device.h>
 #include <linux/of_mdio.h>
 #include <linux/phy.h>
@@ -754,7 +755,8 @@ struct mii_bus *of_mdio_find_bus(struct device_node *mdio_bus_np)
 	if (!mdio_bus_np)
 		return NULL;
 
-	d = class_find_device_by_of_node(&mdio_bus_class, mdio_bus_np);
+	d = class_find_device_by_fwnode(&mdio_bus_class,
+					of_fwnode_handle(mdio_bus_np));
 	return d ? to_mii_bus(d) : NULL;
 }
 EXPORT_SYMBOL(of_mdio_find_bus);

-- 
2.53.0.959.g497ff81fa9-goog

Re: [PATCH net-next 07/10] net: phy: switch to using class_find_device_by_fwnode()

[Andrew Lunn]

> -	d = class_find_device_by_of_node(&mdio_bus_class, mdio_bus_np);
> +	d = class_find_device_by_fwnode(&mdio_bus_class,
> +					of_fwnode_handle(mdio_bus_np));

When you look at this, why is it better?

     Andew

Re: [PATCH net-next 07/10] net: phy: switch to using class_find_device_by_fwnode()

[Dmitry Torokhov]

On Mon, Mar 23, 2026 at 03:54:09AM +0100, Andrew Lunn wrote:
> > -	d = class_find_device_by_of_node(&mdio_bus_class, mdio_bus_np);
> > +	d = class_find_device_by_fwnode(&mdio_bus_class,
> > +					of_fwnode_handle(mdio_bus_np));
> 
> When you look at this, why is it better?

I think we should move as much as possible towards firmware-agnostic
APIs and use fwnode_handle instead of device_node or software_node or
ACPI companion. To discourage this I think we better remove
firmware-specific APIs where we have firmware-agnostic ones and
eventually clean up drivers that use OF- or ACPI-specific APIs.

Thanks.

-- 
Dmitry

Re: [PATCH net-next 07/10] net: phy: switch to using class_find_device_by_fwnode()

[Russell King (Oracle)]

On Sun, Mar 22, 2026 at 10:17:15PM -0700, Dmitry Torokhov wrote:
> On Mon, Mar 23, 2026 at 03:54:09AM +0100, Andrew Lunn wrote:
> > > -	d = class_find_device_by_of_node(&mdio_bus_class, mdio_bus_np);
> > > +	d = class_find_device_by_fwnode(&mdio_bus_class,
> > > +					of_fwnode_handle(mdio_bus_np));
> > 
> > When you look at this, why is it better?
> 
> I think we should move as much as possible towards firmware-agnostic
> APIs and use fwnode_handle instead of device_node or software_node or
> ACPI companion. To discourage this I think we better remove
> firmware-specific APIs where we have firmware-agnostic ones and
> eventually clean up drivers that use OF- or ACPI-specific APIs.

Basically, no. This is wrong.

It may sound like a good goal, but there's an underlying issue. This
goal assumes that the firmware description in OF and ACPI are
indentical.

Sure, looking up devices by fwnode handle makes sense, but looking up
anything that is described in firmware is not suitable for this kind
of conversion, because in doing so, you effectively "port" the DT
bindings to ACPI, and it may not be suitable for ACPI.

So, please don't make wholesale changes that transfer the DT bindings
into ACPI.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

Re: [PATCH net-next 07/10] net: phy: switch to using class_find_device_by_fwnode()

[Dmitry Torokhov]

On Mon, Mar 23, 2026 at 08:59:52AM +0000, Russell King (Oracle) wrote:
> On Sun, Mar 22, 2026 at 10:17:15PM -0700, Dmitry Torokhov wrote:
> > On Mon, Mar 23, 2026 at 03:54:09AM +0100, Andrew Lunn wrote:
> > > > -	d = class_find_device_by_of_node(&mdio_bus_class, mdio_bus_np);
> > > > +	d = class_find_device_by_fwnode(&mdio_bus_class,
> > > > +					of_fwnode_handle(mdio_bus_np));
> > > 
> > > When you look at this, why is it better?
> > 
> > I think we should move as much as possible towards firmware-agnostic
> > APIs and use fwnode_handle instead of device_node or software_node or
> > ACPI companion. To discourage this I think we better remove
> > firmware-specific APIs where we have firmware-agnostic ones and
> > eventually clean up drivers that use OF- or ACPI-specific APIs.
> 
> Basically, no. This is wrong.
> 
> It may sound like a good goal, but there's an underlying issue. This
> goal assumes that the firmware description in OF and ACPI are
> indentical.

If they are different then drivers will make allowance for this, like
I2C core or SPI core does. But most of the modern drivers use
firmware-agnostic APIs (device_property_*()).

ACPI has allowance for device tree properties (via PRP0001 HID
entries), and drivers should work with them.

> 
> Sure, looking up devices by fwnode handle makes sense, but looking up
> anything that is described in firmware is not suitable for this kind
> of conversion, because in doing so, you effectively "port" the DT
> bindings to ACPI, and it may not be suitable for ACPI.
> 
> So, please don't make wholesale changes that transfer the DT bindings
> into ACPI.
> 

I am not "transferring" anything, but I want to make sure the code works
even if we augment OF with software nodes or if DT properties are used
in ACPI.

Thanks.

-- 
Dmitry

Re: [PATCH net-next 07/10] net: phy: switch to using class_find_device_by_fwnode()

[Russell King (Oracle)]

On Mon, Mar 23, 2026 at 11:33:36AM -0700, Dmitry Torokhov wrote:
> On Mon, Mar 23, 2026 at 08:59:52AM +0000, Russell King (Oracle) wrote:
> > On Sun, Mar 22, 2026 at 10:17:15PM -0700, Dmitry Torokhov wrote:
> > > On Mon, Mar 23, 2026 at 03:54:09AM +0100, Andrew Lunn wrote:
> > > > > -	d = class_find_device_by_of_node(&mdio_bus_class, mdio_bus_np);
> > > > > +	d = class_find_device_by_fwnode(&mdio_bus_class,
> > > > > +					of_fwnode_handle(mdio_bus_np));
> > > > 
> > > > When you look at this, why is it better?
> > > 
> > > I think we should move as much as possible towards firmware-agnostic
> > > APIs and use fwnode_handle instead of device_node or software_node or
> > > ACPI companion. To discourage this I think we better remove
> > > firmware-specific APIs where we have firmware-agnostic ones and
> > > eventually clean up drivers that use OF- or ACPI-specific APIs.
> > 
> > Basically, no. This is wrong.
> > 
> > It may sound like a good goal, but there's an underlying issue. This
> > goal assumes that the firmware description in OF and ACPI are
> > indentical.
> 
> If they are different then drivers will make allowance for this, like
> I2C core or SPI core does. But most of the modern drivers use
> firmware-agnostic APIs (device_property_*()).

What is appropriate is up to the standards bodies responsible for
the firmware. ACPI has a separate body, and we can't just dump
the structure we use for networking into ACPI. So no, you can't
just switch to firmware-agnostic APIs for networking.

For infrastructure where we lookup stuff by some kind of firmware
node, I have no problem with converting that to fwnode APIs,
because that doesn't transfer the DT description into other
firmwares without prior agreement of the appropriate firmware
standards bodies.

This is not "foreign territory" - ACPI in general doesn't want to
describe e.g. the individual components of a network card, unlike
DT.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

Re: [PATCH net-next 07/10] net: phy: switch to using class_find_device_by_fwnode()

[Dmitry Torokhov]

On Mon, Mar 23, 2026 at 06:39:28PM +0000, Russell King (Oracle) wrote:
> On Mon, Mar 23, 2026 at 11:33:36AM -0700, Dmitry Torokhov wrote:
> > On Mon, Mar 23, 2026 at 08:59:52AM +0000, Russell King (Oracle) wrote:
> > > On Sun, Mar 22, 2026 at 10:17:15PM -0700, Dmitry Torokhov wrote:
> > > > On Mon, Mar 23, 2026 at 03:54:09AM +0100, Andrew Lunn wrote:
> > > > > > -	d = class_find_device_by_of_node(&mdio_bus_class, mdio_bus_np);
> > > > > > +	d = class_find_device_by_fwnode(&mdio_bus_class,
> > > > > > +					of_fwnode_handle(mdio_bus_np));
> > > > > 
> > > > > When you look at this, why is it better?
> > > > 
> > > > I think we should move as much as possible towards firmware-agnostic
> > > > APIs and use fwnode_handle instead of device_node or software_node or
> > > > ACPI companion. To discourage this I think we better remove
> > > > firmware-specific APIs where we have firmware-agnostic ones and
> > > > eventually clean up drivers that use OF- or ACPI-specific APIs.
> > > 
> > > Basically, no. This is wrong.
> > > 
> > > It may sound like a good goal, but there's an underlying issue. This
> > > goal assumes that the firmware description in OF and ACPI are
> > > indentical.
> > 
> > If they are different then drivers will make allowance for this, like
> > I2C core or SPI core does. But most of the modern drivers use
> > firmware-agnostic APIs (device_property_*()).
> 
> What is appropriate is up to the standards bodies responsible for
> the firmware. ACPI has a separate body, and we can't just dump
> the structure we use for networking into ACPI. So no, you can't
> just switch to firmware-agnostic APIs for networking.

So I believe there is a difference between deciding:

1. What schema is being used on a particular system - it may be
OF-compatible, or ACPI compatible one, and ACPI may support
OF-compatible schemes for certain subsystems or individual devices, and

2. What is the API to access the properties.

There is no harm to use device_property_read_*() universally as well as 
not having OF-specific APIs at the driver core level. What matters is
schema matches the system type.

> 
> For infrastructure where we lookup stuff by some kind of firmware
> node, I have no problem with converting that to fwnode APIs,
> because that doesn't transfer the DT description into other
> firmwares without prior agreement of the appropriate firmware
> standards bodies.
> 
> This is not "foreign territory" - ACPI in general doesn't want to
> describe e.g. the individual components of a network card, unlike
> DT.

I think we actually broadly agree? What you are arguing against is
saying that OF schema is guaranteed to work on ACPI systems and vice
versa, but I am not saying that (although for some things it may). But
still most OF schema can be handled by generic APIs (either
device_property_read_*() or fwnode ones).

Thanks.

-- 
Dmitry

Re: [PATCH net-next 07/10] net: phy: switch to using class_find_device_by_fwnode()

[Andrew Lunn]

> This is not "foreign territory" - ACPI in general doesn't want to
> describe e.g. the individual components of a network card, unlike
> DT.

It has also been suggested that the MDIO bus should be added to the
ACPI specification as a first class bus, similar to I2C, SPI,
etc. This would make it different to the DT. So we don't want to
encourage developers to use the networking DT concepts in ACPI, it
will just cause problems if the ACPI spec every actually covers the
use cases of networking.

     Andrew

Re: [PATCH net-next 07/10] net: phy: switch to using class_find_device_by_fwnode()

[Dmitry Torokhov]

On Mon, Mar 23, 2026 at 09:15:11PM +0100, Andrew Lunn wrote:
> > This is not "foreign territory" - ACPI in general doesn't want to
> > describe e.g. the individual components of a network card, unlike
> > DT.
> 
> It has also been suggested that the MDIO bus should be added to the
> ACPI specification as a first class bus, similar to I2C, SPI,
> etc. This would make it different to the DT. So we don't want to
> encourage developers to use the networking DT concepts in ACPI, it
> will just cause problems if the ACPI spec every actually covers the
> use cases of networking.

BTW, why would not we want to push for the unified binding? They are the
same pieces of hardware...

-- 
Dmitry

Re: [PATCH net-next 07/10] net: phy: switch to using class_find_device_by_fwnode()

[Andrew Lunn]

> BTW, why would not we want to push for the unified binding? They are the
> same pieces of hardware...

I don't think the ACPI committee would be too happy if i ask them to
throw away their standard and just use DT.

ACPI and DT are different and we just have to accept it.

Nobody really cares about describing networking hardware in ACPI, so
there is no need to support it. KISS and keep everything DT.

      Andrew

Re: [PATCH net-next 07/10] net: phy: switch to using class_find_device_by_fwnode()

[Dmitry Torokhov]

On Mon, Mar 23, 2026 at 11:00:05PM +0100, Andrew Lunn wrote:
> > BTW, why would not we want to push for the unified binding? They are the
> > same pieces of hardware...
> 
> I don't think the ACPI committee would be too happy if i ask them to
> throw away their standard and just use DT.

I meant if we are introducing a new to ACPI schema... Not throwing away
existing one.

> 
> ACPI and DT are different and we just have to accept it.
> 
> Nobody really cares about describing networking hardware in ACPI, so
> there is no need to support it. KISS and keep everything DT.

OK, but even for DT I think we should be using device_property_*() and
fwnode_handle.

If there is an ACPI support for mdio it is perfectly valid to use fwnode
handle on an ACPI system to locate an instance of mdio bus. And
hopefully the caller of this function does not really need to parse
properties itself but will use mdio APIs (mii_bus).

Thanks.

-- 
Dmitry

[PATCH 08/10] fpga: bridge: switch to using class_find_device_by_fwnode()

[Dmitry Torokhov]

In preparation to class_find_device_by_of_node() going away switch to
using class_find_device_by_fwnode().

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
 drivers/fpga/fpga-bridge.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/fpga/fpga-bridge.c b/drivers/fpga/fpga-bridge.c
index 8c275bd48a0d..3e04bb4341c7 100644
--- a/drivers/fpga/fpga-bridge.c
+++ b/drivers/fpga/fpga-bridge.c
@@ -9,6 +9,7 @@
 #include <linux/idr.h>
 #include <linux/kernel.h>
 #include <linux/module.h>
+#include <linux/of.h>
 #include <linux/of_platform.h>
 #include <linux/slab.h>
 #include <linux/spinlock.h>
@@ -94,7 +95,8 @@ struct fpga_bridge *of_fpga_bridge_get(struct device_node *np,
 	struct fpga_bridge *bridge;
 	struct device *bridge_dev;
 
-	bridge_dev = class_find_device_by_of_node(&fpga_bridge_class, np);
+	bridge_dev = class_find_device_by_fwnode(&fpga_bridge_class,
+						 of_fwnode_handle(np));
 	if (!bridge_dev)
 		return ERR_PTR(-ENODEV);
 

-- 
2.53.0.959.g497ff81fa9-goog

[PATCH 09/10] fpga: manager: switch to using class_find_device_by_fwnode()

[Dmitry Torokhov]

In preparation to class_find_device_by_of_node() going away switch to
using class_find_device_by_fwnode().

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
 drivers/fpga/fpga-mgr.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/fpga/fpga-mgr.c b/drivers/fpga/fpga-mgr.c
index 2672070ced02..1e7585a4608a 100644
--- a/drivers/fpga/fpga-mgr.c
+++ b/drivers/fpga/fpga-mgr.c
@@ -716,7 +716,8 @@ struct fpga_manager *of_fpga_mgr_get(struct device_node *node)
 	struct fpga_manager *mgr;
 	struct device *mgr_dev;
 
-	mgr_dev = class_find_device_by_of_node(&fpga_mgr_class, node);
+	mgr_dev = class_find_device_by_fwnode(&fpga_mgr_class,
+					      of_fwnode_handle(node));
 	if (!mgr_dev)
 		return ERR_PTR(-ENODEV);
 

-- 
2.53.0.959.g497ff81fa9-goog

[PATCH 10/10] driver core: class: remove class_find_device_by_of_node()

[Dmitry Torokhov]

All users of class_find_device_by_of_node() have been converted to
using class_find_device_by_fwnode(). Remove the former.

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
 include/linux/device/class.h | 12 ------------
 1 file changed, 12 deletions(-)

diff --git a/include/linux/device/class.h b/include/linux/device/class.h
index 2079239a5aa5..e6ad009ce70b 100644
--- a/include/linux/device/class.h
+++ b/include/linux/device/class.h
@@ -107,18 +107,6 @@ static inline struct device *class_find_device_by_name(const struct class *class
 	return class_find_device(class, NULL, name, device_match_name);
 }
 
-/**
- * class_find_device_by_of_node : device iterator for locating a particular device
- * matching the of_node.
- * @class: class type
- * @np: of_node of the device to match.
- */
-static inline struct device *class_find_device_by_of_node(const struct class *class,
-							  const struct device_node *np)
-{
-	return class_find_device(class, NULL, np, device_match_of_node);
-}
-
 /**
  * class_find_device_by_fwnode : device iterator for locating a particular device
  * matching the fwnode.

-- 
2.53.0.959.g497ff81fa9-goog

Re: [PATCH 10/10] driver core: class: remove class_find_device_by_of_node()

[Greg Kroah-Hartman]

On Sun, Mar 22, 2026 at 06:54:28PM -0700, Dmitry Torokhov wrote:
> All users of class_find_device_by_of_node() have been converted to
> using class_find_device_by_fwnode(). Remove the former.
> 
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> ---
>  include/linux/device/class.h | 12 ------------
>  1 file changed, 12 deletions(-)


Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>