On Mon, 29 Mar 2010 09:58:51 -0700


It does this rather a lot.  it seems to be doing quite a lot of work
under that lock, too - quite a lot of memcpy_toio(), other stuff.

Is there potential here to disable interrupt for too long?  Not
possible to use spin_lock_bh() here?

--

[ message continues ]

Like most similar cards, the host computer communicates to the
microcontroller through a dual ported memory (DPM) interface. In this
card, it is split into 256x 256 byte pages/windows.

The lock ensures that once code sets a window, it doesn't change while

The largest possible memcpy_(to|from)io() in the driver is 256 bytes.
Not too huge, but I understand the concern.

Looking at this again, I don't take the lock in the interrupt handler
(nor do I need to). What contexts do the network driver's xmit() and
napi() routines run in? hardirq and softirq respectively, right? In that
case, I think spin_lock_bh() is probably enough.

Ira
--

[ message continues ]