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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAMRc=Mc9fMrx0bek1mE2kpoxXVgD7GATaeQWZnL1eDW5oZ-FTQ@mail.gmail.com>
Date: Wed, 23 Apr 2025 14:20:30 +0200
From: Bartosz Golaszewski <brgl@...ev.pl>
To: Linus Walleij <linus.walleij@...aro.org>
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 Tue, Apr 22, 2025 at 2:05 PM Linus Walleij <linus.walleij@...aro.org> wrote:
>
> 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;
>

The few use-cases we have for that use regulator notifiers at the
moment and I think async is the way to go here.

Bart