can: add support for Janz VMOD-ICAN3 Intelligent CAN module
in [Kernel]
|
Prev: [PATCH 2/4] exit: change zap_other_threads() to count sub-threads
Next: [PATCH] hwmon: Add basic support for lm64 to lm63.c
From: Andrew Morton on 1 Apr 2010 16:10 On Mon, 29 Mar 2010 09:58:51 -0700 "Ira W. Snyder" <iws(a)ovro.caltech.edu> 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. Is there potential here to disable interrupt for too long? Not possible to use spin_lock_bh() here? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Ira W. Snyder on 1 Apr 2010 20:50
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" <iws(a)ovro.caltech.edu> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |