[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <878s0t6s7p.mognet@arm.com>
Date: Sun, 22 Aug 2021 23:16:10 +0100
From: Valentin Schneider <valentin.schneider@....com>
To: Marc Zyngier <maz@...nel.org>
Cc: Guenter Roeck <linux@...ck-us.net>, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH] irqchip/gic: Convert to handle_strict_flow_irq()
On 18/08/21 17:58, Marc Zyngier wrote:
> On Tue, 17 Aug 2021 01:30:43 +0100,
> Valentin Schneider <valentin.schneider@....com> wrote:
>> Are we guaranteed to have
>>
>> .irq_ack \in {NULL, irq_chip_ack_parent}
>>
>> for all intermediate (!root) irqchips? I don't see why that wouldn't
>> be the case, and with that in mind what you described makes sense to
>> me.
>
> An intermediate layer is allowed to implement its own irq_ack that is
> not irq_chip_ack_parent, but it then has to call irq_chip_ack_parent
> itself.
>
Right, makes sense.
> 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.
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?)
I'm guessing it is *not* chained, which means the irq_set_handler_locked()
affects the entire stack :/
[!!!] Speaking of chained IRQs, I'm now thinking this series breaks them;
chained_irq_enter() + chained_irq_exit() will only issue an ->irq_eoi(),
skipping the ->irq_ack()... One more thing to add to the list!
>>
>> > In order to restore -next into a working state, I'm temporarily
>> > dropping this series. Hopefully, we can sort this out before the merge
>> > window and reinstate it.
>> >
>>
>> I'm away from any keyboard for most of this week, but I'll get to it by the
>> weekend.
>
> No worries, enjoy your break!
>
I sure did, Thanks!
> M.
>
> --
> Without deviation from the norm, progress is not possible.
Powered by blists - more mailing lists