Michael Buesch wrote: > > In general, no. > But, for some sysfs attrs it is sufficient to only take > the mutex, because: > * We don't access hardware. > * We don't modify this data in a spinlock-only critical section. > > Yes, I know that having two locks does not really fit the > "lock data, not code" model. But it's well defined in bcm43xx, > so I think we can live with it. (and we must live with it, > if we want to have preemptible periodic work. And we _want_). > It's defined by the following rules: > > 1) Always take both, mutex and lock. > 2) There are only two places where we can't take the > mutex, but only the spinlock. IRQ and TX paths. > > (Yes, I know that there are still exceptions to 2. > At least in dscape. The softmac port should be OK. > These are bugs, I am aware of them and will fix it) > > So these two rules lead to the following rule: > > * Code where we only take the mutex can race against the > TX and IRQ paths. > Now we come back to the sysfs problem above. If the data, we > access in this sysfs code, is not touched in either TX or IRQ path > we don't need to take the spinlock. Yes, it's a little bit black > magic. So if you aren't sure, always take both locks.
Thanks for the clarification. Larry _______________________________________________ Bcm43xx-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
