Re: [PATCH] ucode debug status via sysfs for wireless-2.6

[Michael Buesch <mb-fseUSCV1ubazQB+pC5nmwQ@public.gmane.org>]

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.