Re: 2.6.17-mm5 + pcmcia/hostap/8139too patches -- inconsistent {hardirq-on-W} -> {in-hardirq-W} usage

[Alan Cox <alan@lxorguk.ukuu.org.uk>]

Ar Llu, 2006-07-03 am 23:43 +0200, ysgrifennodd Arjan van de Ven:
> The ne2000 drivers use disable_irq as a poor mans locking construct;
> make sure lockdep knows about these.

Actually they use it as a locking construct because the kernel lacks the
constructs it needs (or did when the work was done). We don't have a 

spin_lock_disable_irq(lock, n)

construct which some other OS's do. There are also good reasons for not
having one given so few drivers realy need it.

The underlying problem is that the NE2K chips are slow, especially some
of the ones nailed to PCI with FPGA glue. So slow that worst case taking
a spinlock and uploading a packet drops characters at 9600 baud serial.

The driver disables the on chip IRQ, which for 99.9% of cases then
ensures we don't get further interrupts, then takes the lock. An IRQ
running in parallel on another CPU also holds the lock so that much is
fine.
 
However: the people at Intel designed the original APIC bus to be
somewhat slow, asynchronous and also without a guaranteed "one message
send, one message receive" sematic of any kind.

That means we have a corner case where we also have to
disable_irq_nosync to ensure that an IRQ that left the 8390 but has not
yet arrived at the processor doesn't race with us and lock up the box.
PCI posting is not the issue here, the IRQ bus is itself even more async
than that.

Doing that work means our tx path doesn't totally trash the machine in
these cases.

Alan