That sounds broken. What's the point in giving the irq number at
all, then?
I agree that more people should use the "dev" argument, but it
still sounds like Linux/sparc is passing the interrupt handler a
completely bogus numebr that is not useful for anything at all?
What gets passed currently is the CPU irq level the interrupt came in
on. I agree this is inconsistant, but I didn't change it to pass in
the full 32-bit cookie because _so_ many broken PCI drivers did have
0-->NR_IRQS arrays to hold lists of devices hanging off that
"interrupt level". Now that this is all fixed I can go back and
really pass in the true 32-bit full IRQ number which was passed to
request_irq().
But I ask that for the moment, during the transition phase, the old
hack is put back in for the sake of sparc_v9 for now. In the mean
time, I'll update our IRQ handling mechanism to pass in the right
number and then we can remove the IDE driver hack, it's the only
generic driver which compares IRQ numbers like this.
Later,
David S. Miller
davem@dm.cobaltmicro.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu