On Tuesday 18 December 2007 15:41:04 Ehud Gavron wrote: > > Michael Buesch wrote: > > On Tuesday 18 December 2007 13:31:20 Ehud Gavron wrote: > > > >> Michael Buesch wrote: > >> > >>> On Tuesday 18 December 2007 12:37:04 Ehud Gavron wrote: > >>> > >>> > >>>> Ehud Gavron wrote: > >>>> > >>>> > >>>>> If I manually turn the LED on (with the keyboard sequence for > >>>>> KEY_WLAN), rfkill will turn the LED off when I turn the radio off > >>>>> consistently but without the wait will never turn the LED back on. > >>>>> > >>>>> > >>>> That makes no sense; let me rephrase. > >>>> > >>>> I can turn the LED on manually. Then when I turn the radio switch off, > >>>> rfkill turns the LED off every time. > >>>> So the "LED OFF by rfkill" works fine. > >>>> > >>>> No matter what I do... without that delay, rfkill will not turn the LED > >>>> back on, despite the event clearly being called by code. > >>>> > >>>> > >>>> > >>>> > >>>> > >>> What happens if you completely remove the code that sends the two events? > >>> > >>> > >>> > >> The LED never comes on. > >> > >> I can make it come on/off with the key function, and if it's on and the > >> radio is turned off the LED goes off. > >> > >> In other words I'm sure the hardware is turning the LED (and the BT LED) > >> off. > >> I'm also sure the hardware is not turning the LED back on. > >> > >> What other tests would you like me to do? > >> > > > > I have no idea. But I don't understand why waiting a random time up to > > 1000ms fails > > and a random time up to 1000ms + 1ms succeeds. > > > You are right. Here are the tests I've done: > 1. msleep(0) doesn't work. msleep(1) or higher does > 2. remove msleep and set the poll interval to 3000ms, and I turn the > radio on... and 2-3 seconds later b43 says "ENABLED" but the LED does > not work. > 3. the code in b43_rfkill_poll between the "ENABLED" message and where > I'm putting the msleep() is one mutex unlock which was acquired ten > lines previously so I can't see how that's relevant. > > Unless there's some weird race condition where releasing the mutex > allows something else to happen which in its first 1msec prevents the > keyboard event... I don't get it. > > Would there be any harm in moving the mutex to after the > input_report_key sequence?
It is possible that reading the "hw radio enabled" bit from hardware has some sideeffect that needs one msec to trigger. But I doubt this myself. :) -- Greetings Michael. _______________________________________________ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
