> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
