> That is how almost every other operating system that uses polled interrupts
> does it. The handler returns one defined value if they didn't handle it and
> a different value if it was handled.
>
> I was surprised that Linux didn't have the driver poll routine return a
> value.
I am not surprised at all when thinking about level-sensitive interrupts
as PCI.
Reading the PCI BUS from the CPU is way-stupid since such a transaction is
not posted. We must avoid that each time it is possible.
A well-designed PCI-device should allow not to do so. Basically, the CPU
would just have clear some flag that is known to cause the interrupt
without having read it at all and then scan some done queue in memory.
Note that if the write is not flushed quickly enough, the interrupt will
be raised again. :)
Anyway, the chip can do (if possible):
- Clear the flag without reading it
- Perform a dummy read to flush the previous write if posted
- Scan some done queue.
This spare a read from the PCI BUS and the C code is still not able to
tell you if it has really cleared something. :)
Between you and me, a driver that missed to clear the interrupt condition
is pretty unlikely to exist.
May-be I am too optimitic ? Am I so ? :)
In my opinion, if you base you interrupt polling on some return value with
PCI, you run the risk to be confused by some cause-to-effect assumption
that does not apply to PCI and just do wrong things.
Basically you must call each interrupt routine once and only once for an
IRQ that is shared and if such a simple thing does not work, then better
to throw away computers and to learn to count on fingers. ;-)
Gérard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/