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
> - 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
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
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!
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
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!
> 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
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
> 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
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
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
© 2016 - 2026 Red Hat, Inc.