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] [thread-next>] [day] [month] [year] [list]

Message-ID: <bacdb2817bfb2b7aa7285c9cf2b2be8f7f64c62c.camel@posteo.de>
Date: Fri, 03 Oct 2025 13:50:11 +0000
From: Markus Probst <markus.probst@...teo.de>
To: Mika Westerberg <mika.westerberg@...ux.intel.com>
Cc: Linus Walleij <linus.walleij@...aro.org>, Bartosz Golaszewski
	 <brgl@...ev.pl>, 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 Fri, 2025-10-03 at 15:04 +0200, Markus Probst wrote:
> On Fri, 2025-10-03 at 11:05 +0200, Mika Westerberg wrote:
> > On Fri, Oct 03, 2025 at 08:44:12AM +0000, Markus Probst wrote:
> > > On Fri, 2025-10-03 at 06:54 +0200, Mika Westerberg wrote:
> > > > Hi,
> > > > 
> > > > On Thu, Oct 02, 2025 at 09:58:05PM +0000, Markus Probst wrote:
> > > > > sometimes it is necessary to use both acpi and device tree to
> > > > > declare
> > > > > 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
> > > > > can't be easily disabled in acpi and then redeclared in
> > > > > device
> > > > > tree, as
> > > > > it often gets used by other devices declared in acpi (e.g.
> > > > > via
> > > > > GpioInt or
> > > > > GpioIo). Thus a disable of acpi and migration to device tree
> > > > > is
> > > > > not
> > > > > always
> > > > > possible or very time consuming, while acpi by itself is very
> > > > > limited and
> > > > > not always sufficient. This won't affect most configurations,
> > > > > as
> > > > > most of
> > > > > the time either CONFIG_ACPI or CONFIG_OF gets enabled, not
> > > > > both.
> > > > 
> > > > Can you provide a real example where this kind of mixup can
> > > > happen?
> > > 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. (defining a fixed-regulator for the usb vbus for
> > > example)
> > 
> > Okay regulators are Power Resources in ACPI.
> I did look into it and using a ssdt overlay sounds like a better idea
> than using a devicetree, but there is another problem with it. I
> cannot
> define a PowerResource that uses a gpio to control it (or at least
> haven't found any docs on it). The gpio controller uses AMDI0030 and
> is
> handled by the linux kernel driver (not acpi). An ACPI method can't
> talk to the driver to set it.
Okay, there is actually a way, using the gpio operation regions added
in 473ed7be0da041275d57ab0bde1c21a6f23e637f.
If this works, it would make this patch obsolete (for me), assuming
there is not another issue with it.
> 
> Maybe there is a way to expose a kernel function to acpi instead?
> 
> - Markus Probst
> > 
> > > > The
> > > > ACPI ID PRP0001 specifically was added to allow using DT
> > > > bindings
> > > > in
> > > > ACPI
> > > > based systems.
> > > Hmm, would requiring patching of the acpi tables. Not sure if it
> > > would
> > > work with the fixed-regulator though, as it uses dev->of_node
> > > instead
> > > of dev->fwnode. I will try to see if I can make it work this way.
> > 
> > I think you can do this by using SSDT overlays instead of patching
> > the
> > tables:
> > 
> > https://docs.kernel.org/admin-guide/acpi/ssdt-overlays.html
> > 
> > There is configfs interface too.