Search Linux Wireless

Re: [RFC V2] b43: A patch for control of the radio LED using rfkill

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 18 Sep 2008, Michael Buesch wrote:
> 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?

Let me actually understand what Ivo means, and I will get back to you.

What he DOES NOT want is to have any RADIO state (as in stuff that takes
into account set txpower off, etc) being fed back into the rfkill core.

And I have no idea of that stuff you read from mac80211 has them mixed in,
or is exclusive for rfkill.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
--
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

[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux