[PATCH] libertas: fix spinlock recursion bug
hs4233 at mail.mn-solutions.de
Wed Mar 26 11:37:45 EDT 2008
> I agree the indirection in the current SDIO and USB drivers
> sucks, but I'm getting more and more convinced that the way
> that the CF driver is handling this sucks too.
I don't really can say anything about CF/SDIO driver, but for me
several things aren't coming into picture:
a) in "struct lbs_private", we have "struct mutex lock". What
exactly does it lock? Above it is a comment "/* protected with
big lock */" but it's not clear to me to what this comment
refers. Some lines below is the same comment, so maybe this
should be a /* this variables are protected by 'lock' */"
and "/* end of protection by 'lock' */".
b) some lines later there is a comment "/* command related
variables protected by priv->driver_lock */", but some
variables, like priv->seqnum, are command-related, but in
the "struct mutex lock" section.
c) then there is the "spinlock_t driver_lock" later. Maybe this
is what is meant to protect command-related things.
d) my knowledge about locks is so non-existant that I currently
don't know why one lock is a "struct mutex" and the other is
e) I also don't know (yet) when to use spin_lock_irq,
spin_lock_irqsave or a plain spin_lock. However, I hope to fill
this knowledge gap with
But for clarification of the other points I'd need a helping
hand :-) Once we know which variables should be protected by
which lock we can go and fix this thing. It might even be the
case that one lock is enought.
More information about the libertas-dev