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

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

On Tue, Mar 24, 2026 at 02:46:06AM -0700, Bartosz Golaszewski wrote:
> On Tue, 24 Mar 2026 05:46:50 +0100, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> 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 :) ).

But having them is strongly encouraged anyways.

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

Please post the reworked version so we can review all the details. My
concern was that it relies on notifier chains to notify when devices
get registered and unregistered, and instead of matching node names you
now need to somehow match device instances and software node instances,
which again likely is done based on some name. This just piles on
complexity where a simpler solution would be sufficient.

I think this approach also will give trouble when there are multiple
users of GPIOs provided by the same gpiochip, in cases where users are
split across multiple modules.

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

It does not limit, it only provides additional opportunity when a simple
case is enough. We are not replacing seoftware node instance in the
reference with name, we allow using either, depending on user's wishes.
So it does not preclude also having the mechanism that you propose when
you need more complex management.

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

OK, I am fine with making it a subsystem's decision.

Thanks.

-- 
Dmitry