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] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMRc=Medke+Dr7ti6OpMW6j=RDU0AO19pJUmPa_cvSXyW16OPw@mail.gmail.com>
Date: Tue, 7 Oct 2025 09:49:56 +0200
From: Bartosz Golaszewski <brgl@...ev.pl>
To: Krzysztof Kozlowski <krzk@...nel.org>
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 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.

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

Bartosz

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ