lkml.org 
[lkml]   [2008]   [Nov]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2008-11-18 09:37    [W:0.099 / U:0.820 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site