lkml.org 
[lkml]   [2008]   [Jun]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Locking in the (now generic) GPIO infrastructure?
Date
On Friday 06 June 2008, Leon Woestenberg wrote:
> In fact, on the IXP4xx, gpio_set_value() is just gpio_line_set(),

OK, so the generic GPIO calls are inheriting a locking bug
from the older code. Calls to the older stuff should probably
start getting phased out.


> so I
> think it is valid to understand where the locking should occur (lowest
> level, higher level?)
>
> > most spinlocks to establish its atomicity guarantee; it's
> > described as "spinlock-safe", and in distinction to the
> > gpio_set_value_cansleep() call which could use a mutex or
> > other sleeping synch primitive.
> >
>
> So, the solution (for the upstream work on -rt) would be to add
> spinlock protection to gpio_line_set(), mutex protection for
> _cansleep() variants?

Given this is on -RT, yes it seems like a spinlock is needed
to protect against preemption (but not against concurrency,
which those XScale chips don't provide).

Though with that addition, the size of that function exceeds
what I'd call appropriate to inline.

- Dave



\
 
 \ /
  Last update: 2008-06-06 22:15    [W:0.274 / U:0.112 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site