Re: [PATCH] gpio: of: make it possible to reference gpios probed in acpi in device tree

[Krzysztof Kozlowski]

On 07/10/2025 16:49, Bartosz Golaszewski wrote:
> On Tue, Oct 7, 2025 at 3:14 AM Krzysztof Kozlowski <krzk@xxxxxxxxxx> wrote:
>>
>> On 03/10/2025 17:51, Bartosz Golaszewski wrote:
>>> On Fri, Oct 3, 2025 at 10:40 AM Markus Probst <markus.probst@xxxxxxxxx> wrote:
>>>>
>>>> On Fri, 2025-10-03 at 10:03 +0200, Bartosz Golaszewski wrote:
>>>>> On Thu, Oct 2, 2025 at 11:58 PM Markus Probst
>>>>> <markus.probst@xxxxxxxxx> wrote:
>>>>>>
>>>>>> sometimes it is necessary to use both acpi and device tree to
>>>>>> declare
>>>>>
>>>>> This is a rather controversial change so "sometimes" is not
>>>>> convincing
>>>>> me. I would like to see a user of this added in upstream to consider
>>>>> it.
>>>>>
>>>>>> devices. Not every gpio device driver which has an acpi_match_table
>>>>>> has
>>>>>> an of_match table (e.g. amd-pinctrl). Furthermore gpio is an device
>>>>>> which
>>>>>
>>>>> What is the use-case here because I'm unable to wrap my head around
>>>>> it? Referencing devices described in ACPI from DT? How would the
>>>>> associated DT source look like?
>>>> In my specific usecase for the Synology DS923+, there are gpios for
>>>> powering the usb vbus on (powered down by default), also for powering
>>>> on sata disks. An example for a regulator defined in DT using a gpio in
>>>> ACPI (in this case controlling the power of on of the usb ports):
>>>>
>>>>         gpio: gpio-controller@fed81500 {
>>>>                 acpi-path = "\\_SB_.GPIO";
>>>>                 #gpio-cells = <2>;
>>>>         };
>>>>
>>>>         vbus1_regulator: fixedregulator@0 {
>>>>                 compatible = "regulator-fixed";
>>>>                 regulator-name = "vbus1_regulator";
>>>>                 regulator-min-microvolt = <5000000>;
>>>>                 regulator-max-microvolt = <5000000>;
>>>>                 gpio = <&gpio 0x2a 0x01>;
>>>>         };
>>>>
>>>> - Markus Probst
>>>>>
>>>
>>> Krzysztof: Could you please look at this and chime in? Does this make any sense?
>>
>>
>> There is no such property as acpi-path and I don't see here any ABI
>> being documented. Nothing in dtschema, either. Nothing in DT spec. I
>> also did not receive this patch. Actually - nothing from
>> markus.probst@xxxxxxxxx in mail mailbox.
>>
>> So no clue what is this about, but if you want to use undocumented
>> property then obviously no.
>>
> 
> I interpret this as a vague proposal of adding a way of referencing
> ACPI nodes from DT source and this is my question: does this make any
> sense? It doesn't to me at first glance but we do sometimes describe
> firmware details in DT so I figured I'd ask you.


I am not aware of mixed ACPI+DT systems and it looks like that's the
purpose. And PRP0001 still assumes you are having ACPI system...
https://docs.kernel.org/firmware-guide/acpi/enumeration.html#device-tree-namespace-link-device-id

In any case, we rarely discuss ABI via driver patch. Any discussions
should come via patch proposing this ABI - either to kernel bindings or
to dtschema.

> 
> It seems like Markus found a different solution in the end so it may
> not even be important anymore.
> 
> Bartosz


Best regards,
Krzysztof