Michael Buesch wrote: > On Tuesday 27 November 2007 17:03:57 Larry Finger wrote: > This is not how led triggers work. > You are shortcutting the whole thing here. So you could as well > remove the whole rfkill and LEDs code. It just plain doesn't work now. What I'm trying to do is get something to the users that will restore the behavior they want while we work out the details of the rfkill and LEDs code. > Please properly register the LED in the leds code and > add a default LED trigger for the rfkill trigger. > This has several advantages to the user, among the possiblility to > reassign a LED to a different trigger. How do I do that? >> @@ -70,11 +75,13 @@ static int b43_rfkill_soft_toggle(void * >> struct b43_wldev *dev = data; >> struct b43_wl *wl = dev->wl; >> int err = 0; >> + int lock = mutex_is_locked(&wl->mutex); >> >> if (!wl->rfkill.registered) >> return 0; >> >> - mutex_lock(&wl->mutex); >> + if (!lock) >> + mutex_lock(&wl->mutex); > > Nah, it shouldn't be locked by "current" in the first place, here. > (I guess that's what you are trying to check here). > That's what the !registered check above is for. > This !lock check is racy. If you recall my message from yesterday, I got a locking error. That is what I'm trying to prevent. I know it is racy, but I don't know the correct way to do it. Larry - 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
