Jeff Garzik wrote: > Actually no, and that is a key benefit of this scheme: if we ensure > that the polling paths are resilient even in case where interrupts are > being delivered -- as we must do anyway -- then we don't have to worry > about interrupt masking, either on the interrupt controller or on the > device[1]. > > [1] well, there -are- exceptions, such as when we are bitbanging the ATA > Data register Yeah, that one exception is exactly why we need to plug the IRQ during polling PIO or to push PIO data xfer to a workqueue and doing so by nIEN is unreliable on several controllers and unreliable by nature in many early SFF SATA controllers when paired with certain SATA devices as noted in appendix C of SATA 2.5 spec. And when reading off Status when idle, we'll need to return 0 from irq_handler. That will prevent IRQ screaming IRQ lock and nobody cared detection code is exactly there to watch how often such idle IRQs occur and disable it if necessary. Maybe we can make irqpoll on-demand such that nobody cared turns it and driver can also request polling on the IRQ. Thanks. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
