[PATCH] ARM: gic: use handle_fasteoi_irq for SPIs

[will.deacon@arm.com (Will Deacon)]

> You have to actually use your brain when implementing a chained
> handler. Looking through a bunch of implementations I found stuff,
> which is basically a poorly implemented flow handler. Worst example:
> fsl_msi_cascade().
> 
> ARM ones are mostly sane, but e.g. nmk_gpio_irq_handler() is not
> really one which fits your description. It's trying to deal with
> different underlying primary chips obviously, which is wrong in the
> first place.

Right, so to get back to the original discussion about how to handle
chained handlers if the high-level flow type of the IRQ chip is altered
it seems that there are two options:

1.) Update all of the chained handlers to use the new flow-control
2.) Retain backwards compatibility if a chained handler decides to
    use the old method of flow control (specifically, leave an ack
    implementation in the GIC code after moving to fasteoi).

Obviously, I'd rather go with option (2) and let platforms migrate
over time if they choose to. Now, given that the ack function is really
not something you want to do in a virtualised environment (because it
pokes the distributor), is it worth sticking a
WARN_ON_ONCE(cpu_has_virtualisation()); in the ack code?

Cheers,

Will