[PATCH v3 2/7] gpio: regmap: add gpio_regmap_get_gpiochip() accessor

[Andy Shevchenko]

On Wed, Jul 01, 2026 at 01:38:54PM +0200, Michael Walle wrote:
> On Wed Jul 1, 2026 at 12:55 PM CEST, Andy Shevchenko wrote:
> > On Wed, Jul 01, 2026 at 01:01:10PM +0300, Andy Shevchenko wrote:
> >> On Wed, Jul 1, 2026 at 11:44 AM Michael Walle <mwalle at kernel.org> wrote:
> >> > On Fri Jun 19, 2026 at 11:08 PM CEST, Linus Walleij wrote:
> >> > > On Mon, Jun 8, 2026 at 4:41 PM Michael Walle <mwalle at kernel.org> wrote:
> >> > >
> >> > >> >>> Without an accessor like gpio_regmap_get_gpiochip(), we cannot retrieve the
> >> > >> >>> gpio_chip instantiated inside gpio-regmap.c to fulfill these requirements in our
> >> > >> >>> map() function.
> >> > >>
> >> > >> Why is gpiochip_irq_reqres() called in the first place? Isn't that
> >> > >> only called if the irq handling is set up via gc->irq.chip and not
> >> > >> via gpiochip_irqchip_add_domain() like in gpio-regmap?
> >> > >
> >> > > Not really, the gpiochip_irq_reqres() is called to mark that a
> >> > > GPIO line is used for IRQ, so the gpiolib cannot turn this
> >> > > GPIO into an output line, gpiod_direction_out() will fail
> >> > > on lines used for IRQ. So it's a failsafe.
> >> > >
> >> > > You can live without it of course, but then you don't get
> >> > > this failsafe.
> >> >
> >> > Thanks for the explanation! So did I make a mistake years ago by
> >> > adding the gpiochip_irqchip_add_domain(), see commit 6a45b0e2589f
> >> > ("gpiolib: Introduce gpiochip_irqchip_add_domain()")
> >> >
> >> > As Yu-Chun found, gpiochip_irq_reqres() expect the irq chip data
> >> > to be a gpio_chip, which isn't the case (in general) for an
> >> > externally allocated domain, is it?
> >> 
> >> So the whole issue comes from the fact that the IRQ chip is not marked
> >> as immutable. For immutable IRQ chips (which all GPIO provides should
> >> have) there is no such issue to begin with, id est there is no
> >> gpiochip_irq_reqres() callback assigned (and respective _relres).
> >
> > Ah, for immutable chips we put either custom ones or
> > GPIOCHIP_IRQ_RESOURCE_HELPERS which actually refers to those callbacks.
> >
> > So, if the domain is external, it should also provide irq_request_resources
> > and release callbacks. In the custom case we can wrap gpiochip_reqres_irq()
> > and gpiochip_relres_irq() respectively.
> 
> Exactly. And its seems that this should have been possible with this
> series, too.
> 
> Apart from that, most drivers use regmap-irq with gpio-regmap. For
> this we'd probably have to add something to regmap-irq because that
> module owns the irq_chip.
> 
> > But we need to have a struct gpio_chip pointer for them. And note, the
> > IRQ chip data can be anything in that case, so it's not a requirement.
> 
> That's what I've meant. Conceptionally, it should be part of
> gpiochip_irqchip_add_domain()/gpiolib, so a user doesn't have to
> have that knowledge. But I don't see how this could be achieved.

But it can be hidden in gpio-regmap + regmap-irq.

So, what we need is:
- patch regmap-irq to be able to customize irq_request_resources and release
- provide default callbacks in gpio-regmap (and export for external domains)
- use those callbacks by default when gpio-regmap creates an IRQ chip

The leftovers are the drivers that use gpio-regmap + their own call to
regmap-irq. I haven't looked into them closely, they usually have custom
xlate and something else. OTOH, they will be able to customize the resource
handling as well.

-- 
With Best Regards,
Andy Shevchenko