* Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> wrote: > > Hm, that reads like the boot IRQ erratas of certain chipsets > > - the APIC could throw a fit essentially locking up the > > system. FYI, we have fixes for that upstream already. > > Good - certainly it used to be the case that masking APIC IRQs > and leaving them masked from the IRQ handled used to do funny > things sometimes. I think being careful is definitely warranted in the case of IDE. I'd not be surprised if not all chipsets are mapped via the boot-IRQ quirks: those quirks are opt-in based on PCI IDs - those tend to be the quirk mechanisms with the least coverage. (The IDs were also derived from enterprise testing of -rt, which tends to under-emphasise cheap broken chipsets.) Plus the erratum you described about doing an IRQ masking mid-PIO-transfer confusing the chipset can also be a separate standalone bug not permitting an irq-masking based IRQ flow at all on such hardware. So your worries are spot on IMO and are not being dismissed forcibly. > > i think you severely over-estimate the importance and ratio > > of drivers that enable irqs within irq handlers. (Nor does > > anyone want to break them really - we want to have a sane > > default and we want to flag the broken cases as broken.) > > IDE. A lot less people use the IDE stack nowdays but its a big > item and getting it wrong tends to eat your files. > > I do object to the attitude shown about "forcing" people. It's > a community project built by a large number of people on a mix > of pragmatic and elegant design balances. Maybe it's just > unfortunate choice of wording but it is the wrong sentiment. It was in the heat of the argument i think ... (I do think we need to be somewhat less permissive in terms of weird driver practices, but that's just my opinion and not 'enforced' via any artificial way.) Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
