On Thu, Apr 01, 2010 at 01:03:59PM -0700, Andrew Morton wrote: > On Mon, 29 Mar 2010 09:58:51 -0700 > "Ira W. Snyder" <[email protected]> wrote: > > > The Janz VMOD-ICAN3 is a MODULbus daughterboard which fits onto any > > MODULbus carrier board. It is an intelligent CAN controller with a > > microcontroller and associated firmware. > > > > A neat-looking driver. > > > ... > > > > + spin_lock_irqsave(&mod->lock, flags); > > > > ... > > 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. >
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 memcpy/iowrite happens. > Is there potential here to disable interrupt for too long? Not > possible to use spin_lock_bh() here? > 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 _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
