On Tue, 25 May 2021 18:32:53 +0100,
Valentin Schneider [off-list ref] 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.

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