Re: revert yenta free_irq on suspend

[Linus Torvalds <torvalds@osdl.org>]

On Mon, 1 Aug 2005, Dave Airlie wrote:
> 
> You said earlier we only should fix drivers that need fixing, but they
> all need fixing

I think you're still talking from a theoretical standpoing, while all my 
arguments are practical.

In _practice_, I hope that

 (a) we don't see that very much (ie the people for whom things work 
     already are a strong argument that this is less of a problem in
     practice than people try to make it appear)

 (b) drivers, _especially_ on notebooks, are already able to handle an 
     incoming interrupt with the device in D3 state and returning 0xff
     for all reads.

     In particular, this is exactly the same thing that you get on a 
     surprise device removal too.

iow it really _really_ shouldn't matter that a shared interrupt comes in
after (or before) a device has gone to sleep. Because a driver that can't
handle that schenario is buggy for totally unrelated reasons, and doing a 
"free_irq()/request_irq()" pair at suspend time is _not_ the solution!

> I'm trying to see which way they should be fixed, either the PM people
> say we need request/free irq pairs or say we need to put support code in
> the interrupt handlers,

And I say that's not true. See (b) above. As far as I can tell, the 
"interrupt when in D3" really looks _exactly_ the same as "interrupt when 
device was just removed by the user", and nobody will hopefully argue that 
free_irq/request_irq can protect against forced removal?

> This has nothing to do with the issues with highlevel PM interfaces
> for shutting down hardware, this is do with fixing the drivers in the
> kernel currently and what the correct way to do it is without breaking
> someone elses hardware....

... and I don't think this has _anything_ to do with free_irq/request_irq, 
and everything to do with the fact that we can try to make at least the 
common drivers "hardened" for unexpected interrupts coming in when the hw 
might not be ready for them.

		Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/