Re: revert yenta free_irq on suspend

Linus Torvalds
2005-08-01T01:07:52Z

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