Re: Flexible SFF interrupt handling

[Mark Lord <liml@rtr.ca>]

Mark Lord wrote:
> Jeff Garzik wrote:
>> Mark Lord wrote:
>>> Jeff Garzik wrote:
...
>>> The only question is, under which conditions do we return IRQ 
>>> "handled=1",
>>> and which times should we return 0 ?
>>>
>>> Definitely when a real IRQ wakes us up and we see (qc != NULL && 
>>> drive_ready),
>>> essentially exactly as we currently do it.
>>>
>>> But things might be trickier once polling is introduced, unless we 
>>> also mask
>>> the device interrupt before initiating the polling.
>>
>> 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].
>>
>> If we do get an interrupt, ack it ASAP.  That covers normal operation 
>> and screaming interrupts.
> ..
> 
> I was considering a shared IRQ environment, where the screamer
> might be a different device on the same IRQ..
...

To clarify:  If we are sharing an IRQ line with other device(s),
then it is not good to always return "handled=1" from our IRQ handler
in cases where the interrupt could not be confirmed to be ours.

Because if we did, then the babbling-IRQ detection ("too many spurious")
elsewhere in the kernel will be unable to function for this particular IRQ line.

If we really have no other good option, then fine --> sata_qstor does this.
And I suppose that's the intent --> only fall back to this kind of stuff
when we are dealing with hardware that is known to be unreliable w.r.t. IRQs.

Cheers