[PATCH RFT] driver core: faux: allow to set the firmware node for a faux device

[PATCH RFT] driver core: faux: allow to set the firmware node for a faux device

[Bartosz Golaszewski]

Add a new variant of faux_device_create() taking a firmware node handle
as argument and attaching it to the created faux device. This allows
users to define and read device properties using the standard property
accessors.

While at it: order includes in faux.c alphabetically for easier
maintenance.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
Hi Shivendra et al!

This patch is related to my response to your reboot-mode patch[1].

You should be able to use the new function like:

  faux_device_create_full("psci-reboot-mode", NULL, NULL, NULL, of_fwnode_handle(np));

If it works for you and driver core maintainers accept it, please
integrate it into your series.

[1] https://lore.kernel.org/all/20260304-arm-psci-system_reset2-vendor-reboots-v20-6-cf7d346b8372@oss.qualcomm.com/
---
 drivers/base/faux.c         | 64 ++++++++++++++++++++++++++++++++++++++-------
 include/linux/device/faux.h |  5 ++++
 2 files changed, 60 insertions(+), 9 deletions(-)

diff --git a/drivers/base/faux.c b/drivers/base/faux.c
index fb3e42f213624ac8854764f58e81b9c2bc58cc86..27b3923b461df14bccc07eab701c6e8070de631a 100644
--- a/drivers/base/faux.c
+++ b/drivers/base/faux.c
@@ -10,12 +10,15 @@
  * intended to be very simple, with only a create and a destroy function
  * available.
  */
+
+#include <linux/container_of.h>
+#include <linux/device/faux.h>
 #include <linux/err.h>
+#include <linux/fwnode.h>
 #include <linux/init.h>
 #include <linux/slab.h>
 #include <linux/string.h>
-#include <linux/container_of.h>
-#include <linux/device/faux.h>
+
 #include "base.h"
 
 /*
@@ -95,9 +98,10 @@ static void faux_device_release(struct device *dev)
 }
 
 /**
- * faux_device_create_with_groups - Create and register with the driver
- *		core a faux device and populate the device with an initial
- *		set of sysfs attributes.
+ * faux_device_create_full - Create and register with the driver
+ *		core a faux device described by the properties of the firmware
+ *		node and populate the device with an initial set of sysfs
+ *		attributes.
  * @name:	The name of the device we are adding, must be unique for
  *		all faux devices.
  * @parent:	Pointer to a potential parent struct device.  If set to
@@ -107,6 +111,7 @@ static void faux_device_release(struct device *dev)
  *		into, can be NULL.
  * @groups:	The set of sysfs attributes that will be created for this
  *		device when it is registered with the driver core.
+ * @fwnode:	Firmware node describing this device.
  *
  * Create a new faux device and register it in the driver core properly.
  * If present, callbacks in @faux_ops will be called with the device that
@@ -123,10 +128,11 @@ static void faux_device_release(struct device *dev)
  * * NULL if an error happened with creating the device
  * * pointer to a valid struct faux_device that is registered with sysfs
  */
-struct faux_device *faux_device_create_with_groups(const char *name,
-						   struct device *parent,
-						   const struct faux_device_ops *faux_ops,
-						   const struct attribute_group **groups)
+struct faux_device *faux_device_create_full(const char *name,
+					    struct device *parent,
+					    const struct faux_device_ops *faux_ops,
+					    const struct attribute_group **groups,
+					    struct fwnode_handle *fwnode)
 {
 	struct faux_object *faux_obj;
 	struct faux_device *faux_dev;
@@ -153,6 +159,8 @@ struct faux_device *faux_device_create_with_groups(const char *name,
 		dev->parent = faux_bus_root;
 	dev->bus = &faux_bus_type;
 	dev_set_name(dev, "%s", name);
+	if (fwnode)
+		device_set_node(dev, fwnode);
 	device_set_pm_not_required(dev);
 
 	ret = device_add(dev);
@@ -176,6 +184,44 @@ struct faux_device *faux_device_create_with_groups(const char *name,
 
 	return faux_dev;
 }
+EXPORT_SYMBOL_GPL(faux_device_create_full);
+
+/**
+ * faux_device_create_with_groups - Create and register with the driver
+ *		core a faux device and populate the device with an initial
+ *		set of sysfs attributes.
+ * @name:	The name of the device we are adding, must be unique for
+ *		all faux devices.
+ * @parent:	Pointer to a potential parent struct device.  If set to
+ *		NULL, the device will be created in the "root" of the faux
+ *		device tree in sysfs.
+ * @faux_ops:	struct faux_device_ops that the new device will call back
+ *		into, can be NULL.
+ * @groups:	The set of sysfs attributes that will be created for this
+ *		device when it is registered with the driver core.
+ *
+ * Create a new faux device and register it in the driver core properly.
+ * If present, callbacks in @faux_ops will be called with the device that
+ * for the caller to do something with at the proper time given the
+ * device's lifecycle.
+ *
+ * Note, when this function is called, the functions specified in struct
+ * faux_ops can be called before the function returns, so be prepared for
+ * everything to be properly initialized before that point in time.  If the
+ * probe callback (if one is present) does NOT succeed, the creation of the
+ * device will fail and NULL will be returned.
+ *
+ * Return:
+ * * NULL if an error happened with creating the device
+ * * pointer to a valid struct faux_device that is registered with sysfs
+ */
+struct faux_device *faux_device_create_with_groups(const char *name,
+						   struct device *parent,
+						   const struct faux_device_ops *faux_ops,
+						   const struct attribute_group **groups)
+{
+	return faux_device_create_full(name, parent, faux_ops, groups, NULL);
+}
 EXPORT_SYMBOL_GPL(faux_device_create_with_groups);
 
 /**
diff --git a/include/linux/device/faux.h b/include/linux/device/faux.h
index 9f43c0e46aa45bf492788adcdc081df5cc0c5fc0..ecad00221590e10e63d13698db9234b3c138a492 100644
--- a/include/linux/device/faux.h
+++ b/include/linux/device/faux.h
@@ -54,6 +54,11 @@ struct faux_device *faux_device_create_with_groups(const char *name,
 						   struct device *parent,
 						   const struct faux_device_ops *faux_ops,
 						   const struct attribute_group **groups);
+struct faux_device *faux_device_create_full(const char *name,
+					    struct device *parent,
+					    const struct faux_device_ops *faux_ops,
+					    const struct attribute_group **groups,
+					    struct fwnode_handle *fwnode);
 void faux_device_destroy(struct faux_device *faux_dev);
 
 static inline void *faux_device_get_drvdata(const struct faux_device *faux_dev)

---
base-commit: fc7b1a72c6cd5cbbd989c6c32a6486e3e4e3594d
change-id: 20260306-faux-dev-with-fwnode-5a66c1738158

Best regards,
-- 
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>

Re: [PATCH RFT] driver core: faux: allow to set the firmware node for a faux device

[Greg Kroah-Hartman]

On Fri, Mar 06, 2026 at 02:45:56PM +0100, Bartosz Golaszewski wrote:
> Add a new variant of faux_device_create() taking a firmware node handle
> as argument and attaching it to the created faux device. This allows
> users to define and read device properties using the standard property
> accessors.

Why would a faux device have firmware backing?  Doesn't that mean it
should be a platform device?

> While at it: order includes in faux.c alphabetically for easier
> maintenance.

Hint, that should be a separate patch, and is never something that I
enforce or require in .c files I maintain :)

> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> ---
> Hi Shivendra et al!
> 
> This patch is related to my response to your reboot-mode patch[1].
> 
> You should be able to use the new function like:
> 
>   faux_device_create_full("psci-reboot-mode", NULL, NULL, NULL, of_fwnode_handle(np));

What is the fwnode handle here for?  Why is it required at all?  What
resources are involved that would want this?

thanks,

greg k-h

Re: [PATCH RFT] driver core: faux: allow to set the firmware node for a faux device

[Bartosz Golaszewski]

On Fri, Mar 6, 2026 at 2:54 PM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Fri, Mar 06, 2026 at 02:45:56PM +0100, Bartosz Golaszewski wrote:
> > Add a new variant of faux_device_create() taking a firmware node handle
> > as argument and attaching it to the created faux device. This allows
> > users to define and read device properties using the standard property
> > accessors.
>
> Why would a faux device have firmware backing?  Doesn't that mean it
> should be a platform device?
>
> > While at it: order includes in faux.c alphabetically for easier
> > maintenance.
>
> Hint, that should be a separate patch, and is never something that I
> enforce or require in .c files I maintain :)
>
> > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> > ---
> > Hi Shivendra et al!
> >
> > This patch is related to my response to your reboot-mode patch[1].
> >
> > You should be able to use the new function like:
> >
> >   faux_device_create_full("psci-reboot-mode", NULL, NULL, NULL, of_fwnode_handle(np));
>
> What is the fwnode handle here for?  Why is it required at all?  What
> resources are involved that would want this?
>

Shivendra creates a faux device that registers with the reboot-mode
subsystem which reads the reboot-mode definitions from devicetree. The
faux device needs to have the "reboot-mode" OF-node attached. In his
current proposal, Shivenda had to bypass faux device's probe() because
he can't have the fwnode attached before probe() is called.

Bartosz

Re: [PATCH RFT] driver core: faux: allow to set the firmware node for a faux device

[Greg Kroah-Hartman]

On Fri, Mar 06, 2026 at 03:07:03PM +0100, Bartosz Golaszewski wrote:
> On Fri, Mar 6, 2026 at 2:54 PM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > On Fri, Mar 06, 2026 at 02:45:56PM +0100, Bartosz Golaszewski wrote:
> > > Add a new variant of faux_device_create() taking a firmware node handle
> > > as argument and attaching it to the created faux device. This allows
> > > users to define and read device properties using the standard property
> > > accessors.
> >
> > Why would a faux device have firmware backing?  Doesn't that mean it
> > should be a platform device?
> >
> > > While at it: order includes in faux.c alphabetically for easier
> > > maintenance.
> >
> > Hint, that should be a separate patch, and is never something that I
> > enforce or require in .c files I maintain :)
> >
> > > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> > > ---
> > > Hi Shivendra et al!
> > >
> > > This patch is related to my response to your reboot-mode patch[1].
> > >
> > > You should be able to use the new function like:
> > >
> > >   faux_device_create_full("psci-reboot-mode", NULL, NULL, NULL, of_fwnode_handle(np));
> >
> > What is the fwnode handle here for?  Why is it required at all?  What
> > resources are involved that would want this?
> >
> 
> Shivendra creates a faux device that registers with the reboot-mode
> subsystem which reads the reboot-mode definitions from devicetree. The
> faux device needs to have the "reboot-mode" OF-node attached. In his
> current proposal, Shivenda had to bypass faux device's probe() because
> he can't have the fwnode attached before probe() is called.

Why would a firmware device be attached to a faux device?  A firmware
device is, implicitly, already part of the firmware "device tree", so
there should be something for it to be a child of already in the system.

thanks,

greg k-h

Re: [PATCH RFT] driver core: faux: allow to set the firmware node for a faux device

[Bartosz Golaszewski]

On Fri, Mar 6, 2026 at 3:13 PM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Fri, Mar 06, 2026 at 03:07:03PM +0100, Bartosz Golaszewski wrote:
> > On Fri, Mar 6, 2026 at 2:54 PM Greg Kroah-Hartman
> > <gregkh@linuxfoundation.org> wrote:
> > >
> > > On Fri, Mar 06, 2026 at 02:45:56PM +0100, Bartosz Golaszewski wrote:
> > > > Add a new variant of faux_device_create() taking a firmware node handle
> > > > as argument and attaching it to the created faux device. This allows
> > > > users to define and read device properties using the standard property
> > > > accessors.
> > >
> > > Why would a faux device have firmware backing?  Doesn't that mean it
> > > should be a platform device?
> > >
> > > > While at it: order includes in faux.c alphabetically for easier
> > > > maintenance.
> > >
> > > Hint, that should be a separate patch, and is never something that I
> > > enforce or require in .c files I maintain :)
> > >
> > > > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> > > > ---
> > > > Hi Shivendra et al!
> > > >
> > > > This patch is related to my response to your reboot-mode patch[1].
> > > >
> > > > You should be able to use the new function like:
> > > >
> > > >   faux_device_create_full("psci-reboot-mode", NULL, NULL, NULL, of_fwnode_handle(np));
> > >
> > > What is the fwnode handle here for?  Why is it required at all?  What
> > > resources are involved that would want this?
> > >
> >
> > Shivendra creates a faux device that registers with the reboot-mode
> > subsystem which reads the reboot-mode definitions from devicetree. The
> > faux device needs to have the "reboot-mode" OF-node attached. In his
> > current proposal, Shivenda had to bypass faux device's probe() because
> > he can't have the fwnode attached before probe() is called.
>
> Why would a firmware device be attached to a faux device?  A firmware
> device is, implicitly, already part of the firmware "device tree", so
> there should be something for it to be a child of already in the system.
>

Shivendra: I rememeber there was an issue with using any proper
devices like platform or auxiliary with this but - as the series is
already at v20 - I can't find the actual discussion. Could you please
describe what the issue with driver matching was?

Bartosz

Re: [PATCH RFT] driver core: faux: allow to set the firmware node for a faux device

[Shivendra Pratap]

On 06-03-2026 19:54, Bartosz Golaszewski wrote:
> On Fri, Mar 6, 2026 at 3:13 PM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
>>
>> On Fri, Mar 06, 2026 at 03:07:03PM +0100, Bartosz Golaszewski wrote:
>>> On Fri, Mar 6, 2026 at 2:54 PM Greg Kroah-Hartman
>>> <gregkh@linuxfoundation.org> wrote:
>>>>
>>>> On Fri, Mar 06, 2026 at 02:45:56PM +0100, Bartosz Golaszewski wrote:
>>>>> Add a new variant of faux_device_create() taking a firmware node handle
>>>>> as argument and attaching it to the created faux device. This allows
>>>>> users to define and read device properties using the standard property
>>>>> accessors.
>>>>
>>>> Why would a faux device have firmware backing?  Doesn't that mean it
>>>> should be a platform device?
>>>>
>>>>> While at it: order includes in faux.c alphabetically for easier
>>>>> maintenance.
>>>>
>>>> Hint, that should be a separate patch, and is never something that I
>>>> enforce or require in .c files I maintain :)
>>>>
>>>>> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
>>>>> ---
>>>>> Hi Shivendra et al!
>>>>>
>>>>> This patch is related to my response to your reboot-mode patch[1].
>>>>>
>>>>> You should be able to use the new function like:
>>>>>
>>>>>    faux_device_create_full("psci-reboot-mode", NULL, NULL, NULL, of_fwnode_handle(np));
>>>>
>>>> What is the fwnode handle here for?  Why is it required at all?  What
>>>> resources are involved that would want this?
>>>>
>>>
>>> Shivendra creates a faux device that registers with the reboot-mode
>>> subsystem which reads the reboot-mode definitions from devicetree. The
>>> faux device needs to have the "reboot-mode" OF-node attached. In his
>>> current proposal, Shivenda had to bypass faux device's probe() because
>>> he can't have the fwnode attached before probe() is called.
>>
>> Why would a firmware device be attached to a faux device?  A firmware
>> device is, implicitly, already part of the firmware "device tree", so
>> there should be something for it to be a child of already in the system.
>>
> 
> Shivendra: I rememeber there was an issue with using any proper
> devices like platform or auxiliary with this but - as the series is
> already at v20 - I can't find the actual discussion. Could you please
> describe what the issue with driver matching was?

reboot-mode node is a property of psci which defines the reboot 
commands.‌ As its not an actual device we wanted to avoid creating 
platform or aux device. few references here:

https://lore.kernel.org/all/rz7tnl5gg73gtyij3kmwk6hubikfsvu3krekjkpoofpdio6cwe@innio7qvotye/

Till v17, we were exposing an explicit of_node based registration in 
reboot mode and then registering it from psci driver.
Post this, Lorenzo suggested to move this outside of psci and use a faux 
device instead.

thanks,
Shivendra

Re: [PATCH RFT] driver core: faux: allow to set the firmware node for a faux device

[Greg Kroah-Hartman]

On Mon, Mar 09, 2026 at 09:16:19PM +0530, Shivendra Pratap wrote:
> 
> 
> On 06-03-2026 19:54, Bartosz Golaszewski wrote:
> > On Fri, Mar 6, 2026 at 3:13 PM Greg Kroah-Hartman
> > <gregkh@linuxfoundation.org> wrote:
> > > 
> > > On Fri, Mar 06, 2026 at 03:07:03PM +0100, Bartosz Golaszewski wrote:
> > > > On Fri, Mar 6, 2026 at 2:54 PM Greg Kroah-Hartman
> > > > <gregkh@linuxfoundation.org> wrote:
> > > > > 
> > > > > On Fri, Mar 06, 2026 at 02:45:56PM +0100, Bartosz Golaszewski wrote:
> > > > > > Add a new variant of faux_device_create() taking a firmware node handle
> > > > > > as argument and attaching it to the created faux device. This allows
> > > > > > users to define and read device properties using the standard property
> > > > > > accessors.
> > > > > 
> > > > > Why would a faux device have firmware backing?  Doesn't that mean it
> > > > > should be a platform device?
> > > > > 
> > > > > > While at it: order includes in faux.c alphabetically for easier
> > > > > > maintenance.
> > > > > 
> > > > > Hint, that should be a separate patch, and is never something that I
> > > > > enforce or require in .c files I maintain :)
> > > > > 
> > > > > > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> > > > > > ---
> > > > > > Hi Shivendra et al!
> > > > > > 
> > > > > > This patch is related to my response to your reboot-mode patch[1].
> > > > > > 
> > > > > > You should be able to use the new function like:
> > > > > > 
> > > > > >    faux_device_create_full("psci-reboot-mode", NULL, NULL, NULL, of_fwnode_handle(np));
> > > > > 
> > > > > What is the fwnode handle here for?  Why is it required at all?  What
> > > > > resources are involved that would want this?
> > > > > 
> > > > 
> > > > Shivendra creates a faux device that registers with the reboot-mode
> > > > subsystem which reads the reboot-mode definitions from devicetree. The
> > > > faux device needs to have the "reboot-mode" OF-node attached. In his
> > > > current proposal, Shivenda had to bypass faux device's probe() because
> > > > he can't have the fwnode attached before probe() is called.
> > > 
> > > Why would a firmware device be attached to a faux device?  A firmware
> > > device is, implicitly, already part of the firmware "device tree", so
> > > there should be something for it to be a child of already in the system.
> > > 
> > 
> > Shivendra: I rememeber there was an issue with using any proper
> > devices like platform or auxiliary with this but - as the series is
> > already at v20 - I can't find the actual discussion. Could you please
> > describe what the issue with driver matching was?
> 
> reboot-mode node is a property of psci which defines the reboot commands.‌ As
> its not an actual device we wanted to avoid creating platform or aux device.
> few references here:
> 
> https://lore.kernel.org/all/rz7tnl5gg73gtyij3kmwk6hubikfsvu3krekjkpoofpdio6cwe@innio7qvotye/
> 
> Till v17, we were exposing an explicit of_node based registration in reboot
> mode and then registering it from psci driver.
> Post this, Lorenzo suggested to move this outside of psci and use a faux
> device instead.

As this is a "real" device that talks to hardware (i.e. you have a
firmware device representation), please do not use a faux device, that
is not what that interface is for.  Instead, as it is a firmware device,
just use a platform one as you already have a representation of it
somewhere in the system, right?

thanks,

greg k-h

Re: [PATCH RFT] driver core: faux: allow to set the firmware node for a faux device

[Bartosz Golaszewski]

On Mon, Mar 9, 2026 at 4:55 PM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Mon, Mar 09, 2026 at 09:16:19PM +0530, Shivendra Pratap wrote:
> >
> >
> > On 06-03-2026 19:54, Bartosz Golaszewski wrote:
> > > On Fri, Mar 6, 2026 at 3:13 PM Greg Kroah-Hartman
> > > <gregkh@linuxfoundation.org> wrote:
> > > >
> > > > On Fri, Mar 06, 2026 at 03:07:03PM +0100, Bartosz Golaszewski wrote:
> > > > > On Fri, Mar 6, 2026 at 2:54 PM Greg Kroah-Hartman
> > > > > <gregkh@linuxfoundation.org> wrote:
> > > > > >
> > > > > > On Fri, Mar 06, 2026 at 02:45:56PM +0100, Bartosz Golaszewski wrote:
> > > > > > > Add a new variant of faux_device_create() taking a firmware node handle
> > > > > > > as argument and attaching it to the created faux device. This allows
> > > > > > > users to define and read device properties using the standard property
> > > > > > > accessors.
> > > > > >
> > > > > > Why would a faux device have firmware backing?  Doesn't that mean it
> > > > > > should be a platform device?
> > > > > >
> > > > > > > While at it: order includes in faux.c alphabetically for easier
> > > > > > > maintenance.
> > > > > >
> > > > > > Hint, that should be a separate patch, and is never something that I
> > > > > > enforce or require in .c files I maintain :)
> > > > > >
> > > > > > > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> > > > > > > ---
> > > > > > > Hi Shivendra et al!
> > > > > > >
> > > > > > > This patch is related to my response to your reboot-mode patch[1].
> > > > > > >
> > > > > > > You should be able to use the new function like:
> > > > > > >
> > > > > > >    faux_device_create_full("psci-reboot-mode", NULL, NULL, NULL, of_fwnode_handle(np));
> > > > > >
> > > > > > What is the fwnode handle here for?  Why is it required at all?  What
> > > > > > resources are involved that would want this?
> > > > > >
> > > > >
> > > > > Shivendra creates a faux device that registers with the reboot-mode
> > > > > subsystem which reads the reboot-mode definitions from devicetree. The
> > > > > faux device needs to have the "reboot-mode" OF-node attached. In his
> > > > > current proposal, Shivenda had to bypass faux device's probe() because
> > > > > he can't have the fwnode attached before probe() is called.
> > > >
> > > > Why would a firmware device be attached to a faux device?  A firmware
> > > > device is, implicitly, already part of the firmware "device tree", so
> > > > there should be something for it to be a child of already in the system.
> > > >
> > >
> > > Shivendra: I rememeber there was an issue with using any proper
> > > devices like platform or auxiliary with this but - as the series is
> > > already at v20 - I can't find the actual discussion. Could you please
> > > describe what the issue with driver matching was?
> >
> > reboot-mode node is a property of psci which defines the reboot commands.‌ As
> > its not an actual device we wanted to avoid creating platform or aux device.
> > few references here:
> >
> > https://lore.kernel.org/all/rz7tnl5gg73gtyij3kmwk6hubikfsvu3krekjkpoofpdio6cwe@innio7qvotye/
> >
> > Till v17, we were exposing an explicit of_node based registration in reboot
> > mode and then registering it from psci driver.
> > Post this, Lorenzo suggested to move this outside of psci and use a faux
> > device instead.
>
> As this is a "real" device that talks to hardware (i.e. you have a
> firmware device representation), please do not use a faux device, that
> is not what that interface is for.  Instead, as it is a firmware device,
> just use a platform one as you already have a representation of it
> somewhere in the system, right?

While there is indeed a psci node on arm64 platforms, psci itself must
be brought up very early - specifically in setup_arch() - so there's
no platform device associated with it as the driver is called into
before the driver core is initialized. It's just a function called for
a specific compatible value.

Now looking again at Shivendra's patch, the faux device in question is
created from a device_initcall() which makes me think it's not needed
very early. It can actually come up quite late. What I would suggest
is to create a psci platform device (reusing the existing
of_device_id) that would populate its child OF nodes in probe(), in
this case: the reboot-mode driver, which could then also become a real
platform device.

On a completely unrelated note though - Greg: I think this patch could
still be considered because we now have quite a lot of functionality
put into software nodes and already have some auxiliary devices that
use software nodes as a source of device properties/config using the
same API as platform devices (fwnode). I think faux devices could also
profit from it and not necessairly use custom struct. If that sounds
good to you, I may convert one or two faux devices and send a series
with actual users of this.

Bartosz

Re: [PATCH RFT] driver core: faux: allow to set the firmware node for a faux device

[Greg Kroah-Hartman]

On Tue, Mar 10, 2026 at 01:29:53PM +0100, Bartosz Golaszewski wrote:
> On a completely unrelated note though - Greg: I think this patch could
> still be considered because we now have quite a lot of functionality
> put into software nodes and already have some auxiliary devices that
> use software nodes as a source of device properties/config using the
> same API as platform devices (fwnode). I think faux devices could also
> profit from it and not necessairly use custom struct. If that sounds
> good to you, I may convert one or two faux devices and send a series
> with actual users of this.

I don't understand why a device that has a fwnode would ever be a "faux"
device?  Why wouldn't that just be a normal platform device?

faux devices were created to be not platform devices, to take away the
abuse where platform devices were being used because the api was simple
and people wanted a device in the tree somewhere, but there was not
actually any backing platform device present.

So the use of a fwnode here feels very odd to me, what am I missing?

thanks,

greg k-h

Re: [PATCH RFT] driver core: faux: allow to set the firmware node for a faux device

[Bartosz Golaszewski]

On Tue, 10 Mar 2026 13:29:53 +0100, Bartosz Golaszewski <brgl@kernel.org> said:
>> > >
>> > > Shivendra: I rememeber there was an issue with using any proper
>> > > devices like platform or auxiliary with this but - as the series is
>> > > already at v20 - I can't find the actual discussion. Could you please
>> > > describe what the issue with driver matching was?
>> >
>> > reboot-mode node is a property of psci which defines the reboot commands.‌ As
>> > its not an actual device we wanted to avoid creating platform or aux device.
>> > few references here:
>> >
>> > https://lore.kernel.org/all/rz7tnl5gg73gtyij3kmwk6hubikfsvu3krekjkpoofpdio6cwe@innio7qvotye/
>> >
>> > Till v17, we were exposing an explicit of_node based registration in reboot
>> > mode and then registering it from psci driver.
>> > Post this, Lorenzo suggested to move this outside of psci and use a faux
>> > device instead.
>>
>> As this is a "real" device that talks to hardware (i.e. you have a
>> firmware device representation), please do not use a faux device, that
>> is not what that interface is for.  Instead, as it is a firmware device,
>> just use a platform one as you already have a representation of it
>> somewhere in the system, right?
>
> While there is indeed a psci node on arm64 platforms, psci itself must
> be brought up very early - specifically in setup_arch() - so there's
> no platform device associated with it as the driver is called into
> before the driver core is initialized. It's just a function called for
> a specific compatible value.
>
> Now looking again at Shivendra's patch, the faux device in question is
> created from a device_initcall() which makes me think it's not needed
> very early. It can actually come up quite late. What I would suggest
> is to create a psci platform device (reusing the existing
> of_device_id) that would populate its child OF nodes in probe(), in
> this case: the reboot-mode driver, which could then also become a real
> platform device.
>

Actually, the cpuidle-psci-domain driver already binds to that node so it
would need something like:

diff --git a/drivers/cpuidle/cpuidle-psci-domain.c
b/drivers/cpuidle/cpuidle-psci-domain.c
index b9e4ad7d43a3..f583156a6f41 100644
--- a/drivers/cpuidle/cpuidle-psci-domain.c
+++ b/drivers/cpuidle/cpuidle-psci-domain.c
@@ -165,6 +165,10 @@ static int psci_cpuidle_domain_probe(struct
platform_device *pdev)
	if (ret)
		goto remove_pd;

+       ret = devm_of_platform_populate(&pdev->dev);
+       if (ret)
+	       return ret;
+
	pr_info("Initialized CPU PM domain topology using %s mode\n",
		use_osi ? "OSI" : "PC");
	return 0;

Though that also depends on whether we can live with the fact that it can
be disabled in Kconfig.

Bartosz

Re: [PATCH RFT] driver core: faux: allow to set the firmware node for a faux device

[Bartosz Golaszewski]

On Tue, Mar 10, 2026 at 1:43 PM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Tue, Mar 10, 2026 at 01:29:53PM +0100, Bartosz Golaszewski wrote:
> > On a completely unrelated note though - Greg: I think this patch could
> > still be considered because we now have quite a lot of functionality
> > put into software nodes and already have some auxiliary devices that
> > use software nodes as a source of device properties/config using the
> > same API as platform devices (fwnode). I think faux devices could also
> > profit from it and not necessairly use custom struct. If that sounds
> > good to you, I may convert one or two faux devices and send a series
> > with actual users of this.
>
> I don't understand why a device that has a fwnode would ever be a "faux"
> device?  Why wouldn't that just be a normal platform device?
>
> faux devices were created to be not platform devices, to take away the
> abuse where platform devices were being used because the api was simple
> and people wanted a device in the tree somewhere, but there was not
> actually any backing platform device present.
>
> So the use of a fwnode here feels very odd to me, what am I missing?
>

A firmware node can be a dynamic software node created just for that
faux device to pass to it its configuration instead of using a custom
platform data structure.

Bart

Re: [PATCH RFT] driver core: faux: allow to set the firmware node for a faux device

[Bartosz Golaszewski]

On Tue, Mar 10, 2026 at 2:16 PM Bartosz Golaszewski <brgl@kernel.org> wrote:
>
> Actually, the cpuidle-psci-domain driver already binds to that node so it
> would need something like:
>
> diff --git a/drivers/cpuidle/cpuidle-psci-domain.c b/drivers/cpuidle/cpuidle-psci-domain.c
> index b9e4ad7d43a3..f583156a6f41 100644
> --- a/drivers/cpuidle/cpuidle-psci-domain.c
> +++ b/drivers/cpuidle/cpuidle-psci-domain.c
> @@ -165,6 +165,10 @@ static int psci_cpuidle_domain_probe(struct platform_device *pdev)
>         if (ret)
>                 goto remove_pd;
>
> +       ret = devm_of_platform_populate(&pdev->dev);
> +       if (ret)
> +              return ret;
> +
>         pr_info("Initialized CPU PM domain topology using %s mode\n",
>                 use_osi ? "OSI" : "PC");
>         return 0;
>
> Though that also depends on whether we can live with the fact that it can
> be disabled in Kconfig.
>

Sorry for the noise but I forgot to add that in that case, maybe it
would be better to provide an MFD driver binding to the psci node and
creating separate cells for cpuidle-domain and reboot-mode.

Bart

Re: [PATCH RFT] driver core: faux: allow to set the firmware node for a faux device

[Greg Kroah-Hartman]

On Tue, Mar 10, 2026 at 02:18:36PM +0100, Bartosz Golaszewski wrote:
> On Tue, Mar 10, 2026 at 1:43 PM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > On Tue, Mar 10, 2026 at 01:29:53PM +0100, Bartosz Golaszewski wrote:
> > > On a completely unrelated note though - Greg: I think this patch could
> > > still be considered because we now have quite a lot of functionality
> > > put into software nodes and already have some auxiliary devices that
> > > use software nodes as a source of device properties/config using the
> > > same API as platform devices (fwnode). I think faux devices could also
> > > profit from it and not necessairly use custom struct. If that sounds
> > > good to you, I may convert one or two faux devices and send a series
> > > with actual users of this.
> >
> > I don't understand why a device that has a fwnode would ever be a "faux"
> > device?  Why wouldn't that just be a normal platform device?
> >
> > faux devices were created to be not platform devices, to take away the
> > abuse where platform devices were being used because the api was simple
> > and people wanted a device in the tree somewhere, but there was not
> > actually any backing platform device present.
> >
> > So the use of a fwnode here feels very odd to me, what am I missing?
> >
> 
> A firmware node can be a dynamic software node created just for that
> faux device to pass to it its configuration instead of using a custom
> platform data structure.

Ah, ok, that makes a bit more sense, but faux devices should not need
any "configuration" passed to it that I can see, as that would imply
some sort of "resource" that it needs, which implies it has some backing
hardware (i.e. a platform device) :)

Maybe I'm just missing something here, have a real example (other than
this one, which everyone seems confused about) that would need this?

thanks,

greg k-h