[PATCH] ARM: gic: use handle_fasteoi_irq for SPIs

[tglx@linutronix.de (Thomas Gleixner)]

On Thu, 17 Feb 2011, Will Deacon wrote:

> > 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?

#2 is less painful and just works. The fasteoi stuff does not use ack
IIRC so it wont hurt.

vs. the WARN_ON_ONCE(), I have no real opinion.

Thanks,

	tglx