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

[Bartosz Golaszewski <brgl@bgdev.pl>]

On Tue, Apr 22, 2025 at 2:05 PM Linus Walleij <linus.walleij@linaro.org> wrote:
>
> On Thu, Apr 17, 2025 at 8:57 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> > On Tue, Apr 15, 2025 at 11:33 PM Linus Walleij <linus.walleij@linaro.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