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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <6942a236-ac52-4402-a0ab-bd1765e03636@kernel.org>
Date: Tue, 7 Oct 2025 16:57:46 +0900
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Bartosz Golaszewski <brgl@...ev.pl>
Cc: Markus Probst <markus.probst@...teo.de>,
 Linus Walleij <linus.walleij@...aro.org>,
 Mika Westerberg <westeri@...nel.org>,
 Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
 linux-gpio@...r.kernel.org, linux-acpi@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH] gpio: of: make it possible to reference gpios probed in
 acpi in device tree

On 07/10/2025 16:49, Bartosz Golaszewski wrote:
> On Tue, Oct 7, 2025 at 3:14 AM Krzysztof Kozlowski <krzk@...nel.org> wrote:
>>
>> On 03/10/2025 17:51, Bartosz Golaszewski wrote:
>>> On Fri, Oct 3, 2025 at 10:40 AM Markus Probst <markus.probst@...teo.de> 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@...teo.de> 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@...81500 {
>>>>                 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@...teo.de 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