Re: Flexible SFF interrupt handling

[Tejun Heo <htejun@gmail.com>]

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