Re: revert yenta free_irq on suspend

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Sat, 2005-07-30 at 14:10 -0700, Linus Torvalds wrote:
> 
> On Sat, 30 Jul 2005, Russell King wrote:
> > 
> > I don't think so - I believe one of the problem cases is where you
> > have a screaming interrupt caused by an improperly setup device.
> 
> Not a problem.
> 
> The thing is, this is trivially solved by
>  - disable irq controller last on shutdown
>  - re-enable irq controller last on resume
> 
> Think about it. Even if you have screaming irq's (and thus we'll shut
> things down somewhere during the resume), when we then get to re-enable
> the irq controller thing, we'll have them all back again at that point.
> Problem solved.

That is nasty. That means every single driver must be careful not to
ever "wait" for the device interrupt to happen at resume. I'm not
talking about adding a timeout or such (that should be done anyway to
deal with hot unplug) but having something like IDE -> queues wakeup
request and blocks til it's dealt with. That sort of thing. It's
annoying, it means no driver can rely on IRQs actually working in their
resume callback. Not nice.

Also, once a driver has woken up, it doesn't really have an idea that
the rest of the system is not yet fully up (or that it actually is), and
thus doesn't really know if interrupts are still globally off or not if
we implement your scheme. That may cause nasty effects too I suppose...

> You can have variations on this, of course - you can enable the irq
> controller early _and_ late in the resume process. Ie do a minimal "get
> the basics working" early - you might want to make sure that timers etc
> work early on, for example, and then a "fix up the details" thing late.
> 
> An interrupt controller is clearly a special case, so it's worth spending 
> some effort on handling it.
> 
> In contrast, what is _not_ worth doing is screweing over every single
> driver we have.

I'm not fan of the free/request irq on suspend & resume for various
reasons, and I don't think it actually fixes the problem discussed
anyway because of shared interrupts, but heh, the problem is real on x86
it seems (BIOS crap !). Not sure what the best fix is.

Ben.