Hi,

On Wed Jun 17, 2026 at 11:54 AM CEST, Yu-Chun Lin [林祐君] wrote:
> 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'?

Honestly, I'm not sure. I've never done anything with irq domains
except for using the regmap_irq_chip. But from what I can tell is
that GPIOCHIP_IRQ_RESOURCE_HELPERS are tied to the handling with
gc->irq.chip, which isn't used at all if you add the domain via
gpiochip_irqchip_add_domain(). Please correct me if I'm wrong
though.

-michael

> 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