Re: [PATCH] irqchip/gic: Convert to handle_strict_flow_irq()

[Valentin Schneider <valentin.schneider@arm.com>]

On 23/08/21 10:33, Marc Zyngier wrote:
> On Sun, 22 Aug 2021 23:16:10 +0100,
> Valentin Schneider <valentin.schneider@arm.com> wrote:
>>
>> On 18/08/21 17:58, Marc Zyngier wrote:
>> > There is the bizarre case of drivers/gpio/gpio-thunderx.c that changes
>> > the irqchip flow to use either handle_fasteoi_ack_irq or
>> > handle_fasteoi_mask_irq, which won't play very nicely with this.
>> > Someone said Cavium?
>> >
>>
>> Humph...
>>
>> I'm not familiar at all with the gpiolib irqchips, but I was under the
>> impression those would involve chained IRQs (it does appear to be the case
>> for the pl061 GPIOs on a Juno). For those, the innermost desc would be handled
>> via chained_irq_{enter, exit}() [!!!], and the outermost one via whatever
>> flow was installed by the relevant driver.
>
> Not all of them are built like this. There is actually a bunch of
> these build as full hierarchies (QC, nvidia and some others).
>

I see, thanks!

>> I can't easily grok what goes on between that gpio-thunderx.c driver and
>> gpiolib, but since that GPIO chip has
>>
>>         .irq_eoi		= irq_chip_eoi_parent,
>>
>> and
>>
>>         girq->parent_domain =
>>                 irq_get_irq_data(txgpio->msix_entries[0].vector)->domain;
>>
>> (GPIOs hooked to MSI-X? Do I want to know?)
>
> It's good, isn't it? TX1 has all its HW appearing as PCI, even if it
> clearly isn't PCI underneath.
>
>>
>> I'm guessing it is *not* chained, which means the irq_set_handler_locked()
>> affects the entire stack :/
>
> It does. We can probably fix that, but I won't be able to test (my TX1
> was taken away a few months ago...). I'll accept body donations, for
> scientific purposes.
>

Looks like there are still some over on s/packet/equinix/, so I should be
able to poke at one.