Hi,

On Thu Apr 30, 2026 at 11:58 AM CEST, Yu-Chun Lin [林祐君] wrote:
>> >> 3. Hardware Debounce: We also need to support hardware debounce settings per pin,
>> >> which requires custom configuration via set_config mapped to these specific per-pin
>> >> registers.
>> >
>> > Just add a version of an optional .set_config() call to gpio-regmap.c
>> > to handle this using .reg_mask_xlate() per above and add a new
>> > GPIO_REGMAP_CONFIG_OP to the above enum, problem solved.
>> >
>> > If it seems too hard I can write patch 1 & 2 adding this infrastructure
>> > but I bet you can easily see what can be done with gpio-regmap.c
>> > here provided Michael W approves the idea.
>> >
>
> Our .set_config requires mapping specific debounce time values to
> hardware-specific enums and applying a Write-Enable bit.
>
> Would it be better to allow drivers to assign a custom '.set_config' callback
> directly within 'struct gpio_regmap_config'?

Yeah, I don't think there will be much code sharing of
code/functionality for the .set_config callback. A custom
.set_config was proposed many times in the past.

> Additionally, I didn't mention this in my previous email. we also need to
> implement GPIO interrupts. Our hardware design does not fit well with
> 'regmap_irq_chip'. Therefore, I am planning to create our own 'irqdomain' and
> 'irqchip' ops to handle our cascaded interrupts.
>
> Because of this custom IRQ implementation, I would need to use 'readl()/writel()'
> for the IRQ callbacks in the rtd1625 GPIO driver instead of the regmap APIs.
> Do you have any suggestions on how to handle this gracefully while keeping it
> aligned with the regmap infrastructure?

Why can't the MMIO regmap be used for that?

-michael