On Thursday 07 September 2006 15:21, Larry Finger wrote: > Michael Buesch wrote: > > On Thursday 07 September 2006 03:34, Larry Finger wrote: > >> + return -EPERM; > >> + > > > > you want to take the spinlock lock here, too. > > Obviously, I copied the wrong model. Is it correct that one should take both > locks if your code will > touch the hardware, but the mutex lock only is sufficient if your code just > accesses data > structures? This seems to be the pattern in the other bcm43xx_attr_xxxx_show > routines.
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. -- Greetings Michael. _______________________________________________ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
