Re: revert yenta free_irq on suspend

[Dave Airlie <airlied@gmail.com>]

> On Mon, 1 Aug 2005, Dave Airlie wrote:
> >
> > That still doesn't handle the case where a device has an interrupt
> > handler on a shared IRQ and another device on the chain interrupts it
> > after it has suspended its device,
> 
> I don't know why people bother arguing about this. Face the facts: we have
> to do things incrementally. Any design that breaks unmodified drivers is
> by _definition_ broken. You can't fix all drivers, and anybody who starts
> their arguments with "we should just fix drivers" is living in la-la-land.
> 
>

I'm not arguing at all I agree with you, but I think you are missing
the point I'm trying to make,

You said earlier we only should fix drivers that need fixing, but they
all need fixing, 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,

I fail to see how I can fix this very well incrementally, on my
hardware I have a yenta, my patch fixes it to work, on Hughs hardware
he has his yenta sharing IRQs with another driver which doesn't do the
request/free and it breaks, it isn't the yenta drivers fault the other
driver causes the issue, so therefore in order to apply the yenta fix
I need to go around and fix all the other drivers that might share an
interrupt with it before I can get patch accepted so that I don't
break someones machine? this is irrelevant to whether the ACPI link
change is in or not, adding the request/free pairs to one driver can
show up issues in other drivers that share that IRQ..

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

Dave.