Thread (48 messages) 48 messages, 7 authors, 2d ago

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

From: Andy Shevchenko <hidden>
Date: 2026-07-01 12:09:16
Also in: linux-devicetree, linux-gpio, linux-iio, lkml

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:
quoted
On Wed, Jul 01, 2026 at 01:01:10PM +0300, Andy Shevchenko wrote:
quoted
On Wed, Jul 1, 2026 at 11:44 AM Michael Walle [off-list ref] wrote:
quoted
On Fri Jun 19, 2026 at 11:08 PM CEST, Linus Walleij wrote:
quoted
On Mon, Jun 8, 2026 at 4:41 PM Michael Walle [off-list ref] wrote:
quoted
quoted
quoted
quoted
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.
quoted
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


Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help