Search Linux Wireless

Re: [PATCH 04/13] rfkill: add parameter to disable radios by default

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

 



On Tue, 24 Jun 2008, Fabien Crespel wrote:
> Dmitry Baryshkov wrote:
>> Why not add the possibility for each rfkill-enabled radio to supply 
>> it's default state?
>
> Indeed, I think it would be better to let the driver choose the default 
> state (initialization) instead of forcing it when registering. This would 

For drivers dealing with input devices, it makes some sense.  Mind you,
there IS no API you can use for it right now that will work fine, and anyone
dreaming of doing it through rfkill-input will get an earful :-)

We need to add an API to export the global states in rfkill and rfkill
input, first.  platform drivers that are completely sure they know what
they're doing could then use that API to basically call rfkill_toggle_all.

HOWEVER:

1. It requires rfkill's default to be BLOCK.  Otherwise, you can have
   periods while the devices are blocked at system startup (firmware),
   then unblocked during boot (rfkill just loaded), then blocked again
   (platform driver loaded after rfkill).

   I don't see this as much of an issue, since we'd add this functionality
   along with the global state APIs (that need to also address userspace),
   so anyone who likes his radios to start UNBLOCKED would just need to do
   it in his userspace init scripts.

2. It has severe ordering problems if there is more than one driver wanting
   to do it.  It is not that it wouldn't work, but not only the radio might
   be on undesired states until the last driver loads, the end result would
   also depend on WHICH driver loaded last.  Yuck.

   So the functions would be made to lock down after one use.  You'd get one
   "set the initial state" per radio type, plus one for RFKILL_ALL.

3. It is only acceptable for drivers of input devices that issue rfkill
   events.

> allow drivers to restore the device state after a reboot or shutdown 
> (provided the firmware stores it, which is the case at least on my ASUS 
> F3JC laptop).

Sounds interesting.  But is this functionality worth the hassle of
implementing it?

-- 
  "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