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

On Mon, 23 Aug 2021 11:38:58 +0100,
Valentin Schneider [off-list ref] wrote:

On 23/08/21 10:33, Marc Zyngier wrote:

quoted

On Sun, 22 Aug 2021 23:16:10 +0100,
Valentin Schneider [off-list ref] wrote:

quoted

On 18/08/21 17:58, Marc Zyngier wrote:

quoted

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!

quoted

quoted

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.

quoted

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.

That's where mine used to live, but the WoA people decided that I
really didn't need one, and I'm now only allowed to borrow one of the
old eMAGs. If you can pull strings, let me know! :D

	M.

-- 
Without deviation from the norm, progress is not possible.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel