Re: [PATCH] software node: allow referencing software nodes by name

[Bartosz Golaszewski]

On Tue, 24 Mar 2026 05:46:50 +0100, Dmitry Torokhov
<dmitry.torokhov@xxxxxxxxx> said:
> Currently static device properties references require either an
> instance of software node or an instance of fwnode_handle to be
> available when defining a reference property. This may not be very
> convenient when device node is instantiated from a different module
> (which is usually the case).
>

For context: this is a follow up to the discussion we had under my alternative
proposal[1]. This should ba an [RFC] too I think.

Probably unsurprisingly, but I'd like to express my opposition to this idea.
The final decision is not mine to make and we have yet to hear from the swnode
and driver core maintainers but I'll present a couple arguments in favor of the
tighter coupling.

> The original implementation for describing GPIOs using software nodes
> worked around this by creating a detached from gpiochip instances
> software nodes, and performing matching using gpiochip label and node
> name. The gpiolib maintainers rightfully questioned this approach, and
> currently recommend to attach secondary software node to gpiochip
> instance, export the symbol, and use it in board file when instantiating
> static properties. This unfortunately results in tight coupling between
> gpiochip drivers and board code, necessitates creation of header files,
> requires adding Kconfig dependencies, limits options for choosing module
> vs built-in compilation, and alters device initialization/probing order.
>

In my first proposal I did in fact create a header and put the software node
definitions in the pinctrl drivers. Andy pointed out, the software nodes should
live inside the android tablet drivers that rely on them and not in the pinctrl
drivers where they would be attached on all the platforms, not only the tiny
number of the ones that need them. I agree with this and plan on changing that
in my v2.

We also discussed the possibility of returning -EPROBE_DEFER if we resolve
a reference to a remote software node that has not yet been registered as
a firmware node[2] as it's a situation similar to a firmware node for which
no device exists yet.

With the above changes to my series, the problems of link order disappear and
we can create real links at build-time with no need to set names of software
nodes (which are typically not required and only used to display them in sysfs,
unless someone uses them for matching the swnodes to devices that is :) ).

IOW: for v2 of my[1] series I propose to put swnode back into the android
tablets drivers but still use the mechanism that will either wait for the
relevant platform device to appear or look up the matching ACPI node. If the
driver tries to resolve the reference before the software node is registered,
it will simply defer probe, though if we can use the ACPI node and not wait
for the platform device, the registration will have typically happened before
the driver even gets registered.

> Solve the issue by providing an option to use software node name in
> place of the node instance when describing reference properties. When
> evaluating reference driver core will attempt to resolve the name to
> concrete node instance and, in case of GPIO references, will use
> identity match on firmware node to locate corresponding gpiochip device.
>
> This approach has a drawback of needing to know name of the node that
> gpiochip device will be using, however benefits (minimal coupling, no
> need for adding dependencies) outweigh this drawback.
>

And it also limits the ways we can match real firmware nodes to their
complementary and puts that limitation into the very driver core. For my v2,
I'd like to propose additional mechanisms for such matching like looking up
the correct ACPI and OF nodes and using unnamed software nodes.

> To deal cases with software nodes not being created or registered at
> time of look up, assume that the node with matching name will get
> registered eventually and return -EPROBE_DEFER in the meantime.
>

I don't think this should happen in core software node code. The -ENOENT
should be interpreted by whatever subsystem tries to resolve the reference.

> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx>
> ---

I think that with a few changes to the initial idea, referencing software
nodes by their addresses is the way to go. Keep in mind that this is also
quite the corner-case. In other places we have been typically able to easily
assign the software node to their target fwnode as it would be either a legacy
board file or an MFD driver which already knows its cells' layout and
dependencies.

Thanks,
Bartosz

[1] https://lore.kernel.org/all/20260319-baytrail-real-swnode-v1-0-75f2264ae49f@xxxxxxxxxxxxxxxx/
[2] https://lore.kernel.org/all/CAMRc=MdmuOS-5mHGYtsr3jz654rA9moH4Po_rAFdaPBq-5KCZA@xxxxxxxxxxxxxx/