Re: [PATCH RFC v2 0/4] gpio: loongson-64bit: add interrupt support for more models

[Miao Wang]

Hi,

> 2026年10月8日 18:04，Bartosz Golaszewski <brgl@xxxxxxxxxx> 写道：
> 
> On Thu, 1 Oct 2026 20:13:18 +0200, Miao Wang via B4 Relay
> <devnull+shankerwangmiao.gmail.com@xxxxxxxxxx> said:
>> This patch series aims to correctly add interrupt support for GPIO
>> controllers found on more Loongson CPUs. The GPIO controllers in such
>> models do not have a complete intgrated interrupt controller, but choose
>> to delegate interrupt handling to their parent interrupt controller.
>> This sounds like a heirarchical interrupt setup, but what makes it
>> more complex is that multiple GPIO lines in these controllers may share
>> one interrupt line on the parent interrupt controller. The details is
>> described in the third patch.
>> 
>> Signed-off-by: Miao Wang <shankerwangmiao@xxxxxxxxx>
>> ---
> 
> The series looks pretty good. Who is the RFC addressed at in this case? I can't
> really answer the questions from patch 3/4 as I don't know this platform nor am
> I well versed in ACPI. Maybe Cc the GPIO ACPI maintainers for review?

Thanks for your review. The RFC contains two questions, the first is about
the firmware interface, including FDT and ACPI; the second is about the
way handling the delegated IRQs.

Regarding the firmware interface, it is to be decided how to declare
platform irq numbers for the GPIO controller. Such a GPIO controller
may have N gpio lines with M parent interrupt lines (M < N). The
firmware should a) list M irq numbers corresponding to the M parent
interrupt lines or b) list N irq numbers (which might be duplicated)
orresponding to the N gpio lines. Previously b) was chosen by the
kernel driver. However actual ACPI tables found in the published
firmware chose a). The discussion about it happened in [1].

Regarding to the interrupt handling delegation, since there is no
complete interrupt controller integrated with the GPIO controller,
the interrupt handling, including detecting edge triggered interrupts
and masking/unmasking, should be delegated to the parent IRQ controller.
I want to check if my implementation approach is acceptable and not
violating any implicit rules on the interrupt subsystem side.

Cheers,

Miao Wang

[1]: https://lore.kernel.org/all/allOoYUZXocOfk8F@ashevche-desk.local/