[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20081118083346.GB1494@ucw.cz>
Date: Tue, 18 Nov 2008 09:33:47 +0100
From: Pavel Machek <pavel@...e.cz>
To: Richard Purdie <rpurdie@...ys.net>
Cc: Mark Brown <broonie@...nsource.wolfsonmicro.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] leds: Fix locking for WM8350
On Mon 2008-11-17 15:33:15, Richard Purdie wrote:
> On Sat, 2008-11-15 at 19:14 +0000, Mark Brown wrote:
> > On Sat, Nov 15, 2008 at 07:51:20PM +0100, Pavel Machek wrote:
> > > On Sat 2008-11-15 17:50:50, Mark Brown wrote:
> >
> > > > Yes, that'd be safer though I'd be surprised to see systems that could
> > > > trigger it.
> >
> > > Yes, they are uncommon. They exist; SPARC, IIRC. Plus you need
> >
> > Exceptionally uncommon with the systems the WM8350 gets used with -
> > it's a primary PMIC for mobile devices so anything other than
> > uniprocessor ARM would be surprising.
> >
> > > barriers on anything SMP... Just use atomic_t.
> >
> > I was intending to do so next time I spin the patch. Andrew had some
> > other comments and I don't have any test systems when I'm not in the
> > office anyway.
>
> I've not looked in detail at the code but it looks like a maximum of a
> 32 bit value where you don't actually care which write succeeds as long
> as it takes one of the values written? I don't see why that particular
> variable needs any locking or to be atomic?
Yes.. but it would hurt if you find 42 there, right? So atomic_t is
safer. gcc is alowed to do fancy optimalizations on plain integers....
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists