Re: [PATCH] libertas: fix spinlock recursion bug

[Holger Schurig <hs4233@mail.mn-solutions.de>]

> 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 
http://www.kernel.org/pub/linux/kernel/people/rusty/kernel-locking/

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.