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

[Larry Finger <Larry.Finger@lwfinger.net>]

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