Re: [PATCH v3 2/2] platform/x86: x86-android-tablets: enable fwnode matching of GPIO chips

[Bartosz Golaszewski]

On Tue, Apr 28, 2026 at 11:16 AM Hans de Goede <hansg@xxxxxxxxxx> wrote:
>
> Hi Bartosz,
>
> On 27-Apr-26 14:19, Bartosz Golaszewski wrote:
> > In order to allow GPIOLIB to match cherryview and baytrail GPIO
> > controllers by their firmware nodes instead of their names, we need to
> > attach the - currently "dangling" - existing software nodes to their
> > target devices dynamically.
> >
> > We deal with devices described in ACPI so set up a bus notifier waiting
> > for the ADD events. We know the name of the device we're waiting for so
> > match against it and - on match - assign the appropriate software node
> > as the secondary firmware node of the underlying ACPI node. In case the
> > event was emitted earlier than this driver's probe: also make sure the
> > device was not added before.
> >
> > Scheduling fine-grained devres actions allows for proper teardown and
> > unsetting of the secondary firmware nodes.
>
> Thank you for your work on this.
>
> The x86-android-tablets.ko kernel module uses platform_create_bundle()
> so its probe() cannot return -EPROBE_DEFER. IOW it expects all the GPIO
> pins which it needs to already be there when it loads (which so far in
> practice holds, since these x86 GPIO controllers are always builtin
> for various reasons).
>
> This means that there is no need all the notifier stuff. Only adding
> an acpi_bus_find_device_by_name() helper as suggested by Rafael and
> then finding the GPIO controllers and attaching the swnodes is
> necessary.
>
> And if the acpi_bus_find_device_by_name() fails it is ok to fail
> the probe() just like it currently fails when gpiod_get() returns
> -EPROBE_DEFER (or fails for other reasons).
>
> This should nicely simplify this patch.
>

Thanks Hans, I was not aware of this. Given that this is the only
driver needing this quirk, it will indeed make things much simpler.
I'll have a v4 by the end of this week.

Bart