Re: [PATCH RFC 0/2] pinctrl: Add support gpiod_to_irq

[Xianwei Zhao]

Hi Linus,
   Understood. Thank you for your detailed explanation. I will drop 
this patch.

On 2026/6/15 20:59, Linus Walleij wrote:
> > > Hi Xianwei,
> > >
> > > thanks for your patches!
> > >
> > > On Thu, Jun 11, 2026 at 9:54 AM Xianwei Zhao via B4 Relay
> > > <devnull+xianwei.zhao.amlogic.com@xxxxxxxxxx>   wrote:
> > >
> > > > Some users need to obtain an IRQ directly from a GPIO descriptor through gpiod_to_irq().
> > > > Add the required DT binding and implementation to support this use case.
> > > > Since this introduces a new DT property, the property is kept optional to
> > > > maintain compatibility with existing SoCs and DTS files.
> > > To me it looks like you have just re-implemented hierarchical
> > > irqs.
> > >
> > > Look into the section "Infrastructure helpers for GPIO irqchips"
> > > in Documentation/driver-api/gpio/driver.rst, especially towards
> > > the end.
> > >
> > > Solve this by using GPIOLIB_IRQCHIP and a custom
> > > child_to_parent_hwirq() callback to translate the GPIO into
> > > an IRQ.
> > >
> > > To just implement gpiod_to_irq() without any irqchip abstraction
> > > is also broken: you can't force all users to just use this way
> > > to get an IRQ it's excessively restricting.
> > >
> > > Add
> > >
> > >     interrupt-controller: true
> > >
> > >     "#interrupt-cells":
> > >       const: 2
> > >
> > > to the pinctrl node as well so that DT users can simply request
> > > the IRQ from the irqchip inside of the pin controller. It will
> > > be hierarchical and lightweight but an irqchip nevertheless.
> > >
> > > The GPIOLIB_IRQCHIP approach will help you to get this
> > > right.
> > I read the document (Documentation/driver-api/gpio/driver.rst) you
> > pointed me to and found that the corresponding implementation has
> > already been added in this file:
> >
> > https://github.com/torvalds/linux/blob/master/drivers/irqchip/irq-meson-gpio.c
> That is the parent interrupt controller to the pinctrl+gpio isn't it.
>
> It will be even clearer once you use interrupts = <>; instead of
> the hwirq = <>; hack.
>
> > However, it is implemented as a standalone irqchip and is not integrated
> > with the GPIO controller.
> Right, so it is the parent. Of course it it stand alone.
>
> > In this patch, I implemented the GPIO-to-IRQ conversion through
> > gpiod_to_irq(). Users can still obtain the interrupt directly through
> > the interrupt property, for example:
> >
> > interrupts-extended = <&gpio_intc 16 1>;
> >
> > The purpose of this change is to make GPIO-to-IRQ conversion easier for
> > users who do not want to know the actual interrupt number. The interrupt
> > mapping is not fixed and varies between different SoCs, so users should
> > not need to handle the hardware interrupt allocation details.
> This is not why gpiod_to_irq() exists. It is not a convenience function
> that is voluntary to implement.
>
> If you implement gpiod_to_irq() you implement an entire
> irqchip otherwise it is a bug.
>
> If the pin control + GPIO driver should serve IRQ numbers in any
> shape or form, you need to go the whole way and provide a
> hierarchical irqchip.
>
> It doesn't matter if you don't need to set a single bit in the
> pinctrl + GPIO hardware for these IRQs, the fact that they are
> routed internally on the SoC out through the pin control and
> GPIO block by definition makes it hierarchical.
>
> Yours,
> Linus Walleij