[PATCH] libertas: fix spinlock recursion bug

Holger Schurig 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 
a "spinlock_t".

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 mailing list