> 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
