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@xxxxxxxxxx> 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