On Thursday 18 September 2008 16:48:36 Henrique de Moraes Holschuh wrote: > On Thu, 18 Sep 2008, Ivo van Doorn wrote: > > On Thursday 18 September 2008, Henrique de Moraes Holschuh wrote: > > > On Thu, 18 Sep 2008, Larry Finger wrote: > > > > The changes below, along with Henriques patch "[PATCH] rfkill: update > > > > LEDs for all state changes", and the reversion of commit bc19d6e make > > > > the wireless LED toggle correctly. > > > > > > > > This version passes UNBLOCKED to rfkill when the hardware switch > > > > enables the radio. > > > > > > As I said in an email I just sent (unfortunately, after you already sent > > > this patch), whatever goes to rfkill_force_state must be the CURRENT state > > > of the hardware. > > > > > > So, depending on what happens to b43 hardware when the hardware switch > > > enables it (i.e. does it enable for real, ignoring the software rfkill > > > input > > > lines?), this patch might or might not be correct. > > > > As far as I can see the v2 patch is correct, it sends the BLOCK event when > > the > > rfkill key was pressed to block the radio and the UNBLOCK event when the > > rfkill > > key was pressed to unblock the radio. > > If rfkill_force_state() is being used, you MUST send to it the *real* radio > state. Not the cached radio state, not "desired" radio state, not "user > requested" radio state. It has to be the *real* radio state. > > If a device driver is not doing so, it is incorrect and either it must send > the real radio state, or it should be doing something else than calling > rfkill_force_state().
So well. You tell me this way, and Ivo tells me the other way around to not announce SW_BLOCKED state ever. ;) What's actually right? -- Greetings Michael. _______________________________________________ Bcm43xx-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
