* Jon Masters <jcm@xxxxxxxxxx> wrote: > On Mon, 2009-01-12 at 19:47 -0800, Eric W. Biederman wrote: > > Ingo Molnar <mingo@xxxxxxx> writes: > > > > a number of mainline drivers also mask/unmask irqs from within the IRQ > > > handler. It's not particularly smart in a native driver, but can happen - > > > and if we get an active line after that point (and this can happen because > > > the driver is active), we are in trouble. > > > > Yep. Right now it might be simpler to fix the mainline drivers. > > Taking the easy option now doesn't make the pain go away later :) Just > because ACPI doesn't provide a handy description doesn't mean we > shouldn't handle "boot interrupts" - the kernel is riddled with quirks > already to deal with broken, buggy, or just quirky hardware scenarios. > > > We are outside the descriptions provided by ACPI so it requires > > chipset specific knowledge, and a general understanding of how > > chipsets work to actually even comprehend the problem. > > But how does that differ from most other chipset code? I'm not being > belligerent but I'm not seeing how your argument is uniquely special to > this particular situation. Personally, I'm a little biased because I'd > eventually like to see RT merged upstream and I /know/ that's going to > re-open this whole can of worms once again, even if it's "fixed" now. it's not just -rt, but it is also needed for the concept of threaded IRQ handlers - which was discussed at the Kernel Summit to be desired for mainline. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
