Re: revert yenta free_irq on suspend

[Pavel Machek <pavel@ucw.cz>]

Hi!

> > > Why do it _ever_? There is _zero_ upside to doing it, I don't see why you 
> > > want to.
> > 
> > Being able to turn off your soundcard at runtime when you are not
> > using it was one of examples...
> 
> I meant the "ACPI restores irq controller state" thing.
> 
> Just leave it in. There's never any downside. If all the drivers end up 
> doing free_irq/request_irq(), restoring the irq controller state still 
> won't have any negative effect, and it solves the case where you have 
> drivers that don't do it.
> 
> > > Just make ACPI restore the dang thing. It's the right thing to do.
> > 
> > Requires interpretter running with interrupts disabled => ugly :-(.
> 
> I don't see that. What's ugly? I agree that ACPI is ugly, but I do _not_ 
> agree that it's ugly to restore irq controller state with interrupts 
> disabled. It MakesSense(tm) to do so.

ACPI people claim it would mean rewritting lot of code in
interpretter. And they are probably right: restoring irq states is
done via running ACPI AML code, and it may ask you to grab semaphore;
which is something you can't do with interrupts disabled.

So you'd have to teach ACPI interpretter completely different "irq
disabled" mode, and even then it is not clear what to do if AML code
asks you for some "sleeping operation".

[Hey, it should be Len doing this debate, not me. I hope I'll never
have to touch ACPI interpretter.]
								Pavel
-- 
if you have sharp zaurus hardware you don't need... you know my address