Messages in this thread | | | Date | Tue, 18 Nov 2008 09:33:47 +0100 | From | Pavel Machek <> | 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
| |