[RFC PATCH v2 08/10] irqchip/gic-v3-its: Use irq_chip_ack_parent()

[Marc Zyngier]

On Tue, 25 May 2021 18:32:53 +0100,
Valentin Schneider <valentin.schneider at arm.com> wrote:
> 
> Subsequent patches will make the GIC irqchips use a flow handler that
> issues an ->irq_ack(). irqchips of child domains need to handle this.
> 
> Note: I'm very much not fond of this; this is treacherous and explodes if
> any parent chip doesn't have an ->ack() callback. It turns out okay with
> EOImode=0 because handle_fasteoi_irq() doesn't issue any ->ack(), but that
> is very fragile at best.
> 
> An alternative would be to
> o make irq_chip_ack_parent() check the callback against NULL

That's an overhead I'd like to avoid in the general case, given that
we already have a bunch of users.

> o make irq_chip_ack_parent() the default chip->irq_ack() via
>   MSI_FLAG_USE_DEF_CHIP_OPS.

Seem like a reasonable approach: how about a custom irq_ack() callback
that iterates over the hierarchy until it finds an a non-NULL entry?
Flows that don't use ack won't be impacted, users that need ack will
provide one if they want, and the default will do something slightly
slower, but at least unsurprising.

> XXX: what about pMSI and fMSI ?

Same thing. They are just bus-specific domains on top of the ITS
domain, and must follow the same convention.

However, this patch is perfectly acceptable to me (as long as you take
care of platform and fsl -MSI).

Thanks,

	M.

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