[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1338287087.2536.7.camel@sauron.fi.intel.com>
Date: Tue, 29 May 2012 13:24:47 +0300
From: Artem Bityutskiy <dedekind1@...il.com>
To: David Woodhouse <dwmw2@...radead.org>
Cc: Christian Dietrich
<christian.dietrich@...ormatik.uni-erlangen.de>,
Arnd Bergmann <arnd@...db.de>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.de>,
Dmitry Eremin-Solenikov <dbaryshkov@...il.com>,
David Howells <dhowells@...hat.com>,
linux-kernel@...r.kernel.org, linux-mtd@...ts.infradead.org,
alsa-devel@...a-project.org, vamos-dev@...ts.cs.fau.de
Subject: Re: [PATCH] netwinder: nw_gpio_lock is a raw_spinlock_t
On Tue, 2012-05-29 at 11:11 +0100, David Woodhouse wrote:
> On Tue, 2012-05-29 at 12:06 +0200, Christian Dietrich wrote:
> > Since nw_gpio_lock is a raw_spinlock_t it should be used with the
> > raw_spinlock_* functions and not the spinlock_* variants. Functionally
> > this is equivalent at the moment, because the raw_spinlock_t is the
> > first field of spinlock_t, and therefore &nw_gpio_lock ==
> > &(nw_gpio_lock->rlock). But when other spinlock_t functions use other
> > field they read and write random memory.
>
> Hm, why are we exposing a raw spinlock to drivers?
>
> Should we export a helper function (or macro, I suppose) which does the
> appropriate locking *and* the GPIO operation?
AFAIR, raw spinlock is the one that will not be turned into a
"preemptable" spinlock in the RT tree. E.g., this is needed when dealing
with interrupts. And what if not drivers should use them?
But this commit message did not explain still (although I requested)
_why_ it needs a raw spinlock, which problems it solves?
This URL may be useful for Christian:
http://who-t.blogspot.com/2009/12/on-commit-messages.html
I like that blog-post.
--
Best Regards,
Artem Bityutskiy
Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)
Powered by blists - more mailing lists