linux-kernel - Re: [PATCH v2 0/4] gpio: deprecate and track the removal of GPIO workarounds for regulators

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CACRpkdaKBDyd44xPA_kBxR9HVFqfLgcSnd1UDHumyB=m5-B3xQ@mail.gmail.com>
Date: Tue, 22 Apr 2025 14:04:49 +0200
From: Linus Walleij <linus.walleij@...aro.org>
To: Bartosz Golaszewski <brgl@...ev.pl>
Cc: Mark Brown <broonie@...nel.org>, linux-gpio@...r.kernel.org, 
	linux-kernel@...r.kernel.org, 
	Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
Subject: Re: [PATCH v2 0/4] gpio: deprecate and track the removal of GPIO
 workarounds for regulators

On Thu, Apr 17, 2025 at 8:57 PM Bartosz Golaszewski <brgl@...ev.pl> wrote:
> On Tue, Apr 15, 2025 at 11:33 PM Linus Walleij <linus.walleij@...aro.org> wrote:

> > There are precedents for this type of semantic IRQF_SHARED
> > is used whenever two devices share the same IRQ line,
> > and that is something the drivers have to specify, i.e. the
> > driver has to be aware that it may be sharing the IRQ
> > with other devices, and whenever it gets an IRQ it has
> > to check "was it for me?" and in case it was, return
> > IRQ_HANDLED else IRQ_NONE.
> >
>
> First: this flag has existed (as SA_SHIRQ) since before git days and
> could be considered legacy. But also: it's a bit of a different story
> as sometimes you get an interrupt and need to read a specific register
> to check from the status bits whether it concerns you. This never
> happens with a GPIO so I don't think it's a good argument for this
> specific case.

But at the same time Mark describes that drivers using a shared
GPIO cannot really be opaque as to the status changes on the
GPIO line, as it may or may not need to update register contents
depending on whether the line has actually been low or not while
being disabled. Maybe this can be fixed by a per-consumer status
flag in the descriptor such as bool was_toggled;

Yours,
Linus Walleij