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

[Bartosz Golaszewski]

On Thu, 8 Oct 2026 12:21:43 +0200, Miao Wang <shankerwangmiao@xxxxxxxxx> said:
> 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].
>

Unless it impacts DT systems, I'll let Andy handle the ACPI part. Please Cc him
next time as I pointed out under the RFC.

> 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.
>

I'd suggest to run your implementation by Thomas Gleixner because directly
accessing the internals of the parent's irq data looks fishy. For instance:
you call irq_set_type() directly without going through __setup_irq() ->
__irq_set_trigger() which does some additional bookkeeping.

Bartosz