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

[Yu-Chun Lin [林祐君]]

Hi Michael,

> Hi,
>
> On Wed Jun 17, 2026 at 10:36 AM CEST, Yu-Chun Lin [林祐君] 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?
>>>
>>
>> The panic was caused by my driver including 
>> 'GPIOCHIP_IRQ_RESOURCE_HELPERS', which forced the call to 'gpiochip_irq_reqres()' and crashed.
>
> But why did you use it if your irq domain isn't managed by the gpiolib, but rather your own >irq domain? Before going with option #3 I'd double check if that is correct in your driver.
>
> -michael

Do you mean that a custom IRQ domain shouldn't be mixed with gpiolib features like
'GPIOCHIP_IRQ_RESOURCE_HELPERS'?

Additional information: our GPIO controller receives 3 separate interrupt lines.
Because the standard 'regmap_irq_chip' mechanism in 'gpio-regmap' does not support
this multi-line hardware design, we are forced to create our own IRQ domain and pass
it via 'config->irq_domain'. 

Given this constraint (that we must use our own IRQ domain), are you suggesting
that we should implement our own 'irq_request_resources' and
'irq_release_resources' callbacks instead of relying on
'GPIOCHIP_IRQ_RESOURCE_HELPERS'?

But if that is the case, we would much prefer to let the core gpiolib handle
these resource and state management tasks for us *as proposed in option 3), rather 
than duplicating the effort in our driver.

Best Regards,
Yu-Chun