Re: [PATCH v4 01/20] platform/x86: x86-android-tablets: convert Goodix devices to GPIO references

[Hans de Goede <hansg@kernel.org>]

Hi,

On 13-Feb-26 14:41, Bartosz Golaszewski wrote:
> On Thu, Feb 12, 2026 at 6:19 PM Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
>>>>>
>>>>> OTOH, if there are more than one of a such controllers in the system...
>>>>> And it can be found by reading the links that one of them related to
>>>>> a certain GPIO device. So no insisting on this.
>>>>
>>>> If there are multiple such controllers we cannot use a static software
>>>> node anyway as it should not be shared between them.
>>>>
>>>
>>> In such case they should do what OF nodes do (and I'm sure ACPI too):
>>> use some ID to tell them apart.
>>
>> You are missing the point. You will not be able to use a static node and
>> export it. You will need to create a dedicated software node per
>> instance and the provide a lookup mechanism for whoever wants to use
>> them to locate the right one.
>>
> 
> That depends on whether you know the number of instances, doesn't it?
> If that number is static, you create an equivalent number of software
> nodes.

I think there is some miscommunication happening here.

I _believe_ the troublesome case Dmitry is trying to point out
is the following:

1. A single GPIO controller

2. 2 different drivers which need to manually add GPIO info
using a swnode with a properties array with  PROPERTY_ENTRY_GPIO()
entries

A (so far theoretical) example of this might be both the infamous
x86-android-tablets code referring to this single GPIO controller
as well as some ASoC board file under sound/soc/intel/boards/
referring to it. In that case having them both declare a swnode
for the GPIO controller and then both have them attach that
to the GPIO controller themselves (*) will lead to a problem
because only 1 swnode can be attach to the GPIO controller.

The obvious solution is to have the GPIO controller driver
create and attach a swnode and have it export that swnode
so that it can be used in PROPERTY_ENTRY_GPIO() declerations
in multiple drivers consuming GPIOs from that controller.

Note, I'm not entirely sure this is what Dmitry is trying
to say but I think it is. Regardless this is a case which
I've been thinking about how to handle myself :)

Regards,

Hans