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

[Bartosz Golaszewski]

On Thu, Mar 26, 2026 at 9:48 AM Andy Shevchenko
<andriy.shevchenko@xxxxxxxxxxxxxxx> wrote:
>
> On Thu, Mar 26, 2026 at 10:39:09AM +0200, Andy Shevchenko wrote:
> > On Thu, Mar 26, 2026 at 09:34:01AM +0100, Bartosz Golaszewski wrote:
> > > On Thu, Mar 26, 2026 at 9:27 AM Andy Shevchenko
> > > <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote:
> > > > On Wed, Mar 25, 2026 at 05:32:06PM +0100, Bartosz Golaszewski wrote:
> > > > > On Tue, Mar 24, 2026 at 8:30 PM Dmitry Torokhov
> > > > > <dmitry.torokhov@xxxxxxxxx> wrote:
> > > > > >
> > > > > > 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 will post it. Hopefully before the end of the week. I want to cover
> > > > > both OF nodes with paz00 as well as ACPI with android tablets. The
> > > > > latter case will have to wait for devices because there's no way to
> > > > > look up an ACPI node by name that I could idenfity (correct me if I'm
> > > > > wrong).
> > > >
> > > > What do you need from ACPI exactly? The ACPI namespace in the OS is represented
> > > > by set of ACPI handles, each of which is the object pointing out to some object
> > > > in it. Any object in ACPI has a unique path. At any time, after parsing the
> > > > ACPI table(s) into ACPI namespace we may get a handle based on the path.
> > >
> > > DT is unflattened very early into the boot sequence. Is this the case
> > > for ACPI tables as well? Knowing the name of the device (HID + index,
> > > eg.: "INT33FF:00"), can I check if there's a corresponding ACPI node
> > > (of_find_by_path/name() in DT parlance)?
> >
> > I believe so. See how we find a GPIO chip in the gpiolib-acpi-core.c.
> > In the similar way you can try finding any object in ACPI namespace.
> >
> > But note, ":00" is part of device instance name, it's not available
> > in ACPI namespace. There we have HID, UID, et cetera, ":00" is pure
> > Linux kernel thingy.
>
> We have acpi_dev_present(), but if you read its kernel-doc, it suggests
> to use acpi_get_devices() for the case of early checks (before device
> are actually being instantiated).
>

Ah, but I'm seeing that the firmware node handle of the acpi device is
part of struct acpi_device and is only initialized during the scanning
phase which happens at subsys_initcall() time? When using
acpi_get_devices() you have an abstract handle and no fwnode for which
to assign the secondary node yet, right?

It's not like with DT where there already is an instance of struct
device_node to which you can assign the secondary fwnode even if its
device doesn't exist yet.

Bart