On Wed, Jun 4, 2008 at 11:27 PM, Dan Williams <dcbw@xxxxxxxxxx> wrote: > On Wed, 2008-06-04 at 00:10 -0300, Henrique de Moraes Holschuh wrote: >> rfkill really should have been named rfswitch. As it is, one can get >> confused whether RFKILL_STATE_ON means the KILL switch is on (and >> therefore, the radio is being *blocked* from operating), or whether it >> means the RADIO rf output is on. >> >> Clearly state that RFKILL_STATE_ON means the radio is *unblocked* from >> operating (i.e. there is no rf killing going on). > > Looking over the rfkill stuff again, I think we have a problem. There > are actually 3 states for each radio: > > a) radio on > b) radio off, softkilled by NM, user, or whatever > c) radio off, hardkilled by a physical switch > > I don't think that the rfkill layer can represent this, since the > 'state' member of /sys/class/rfkill/rfkillX is only 0 or 1. You should > be able to simulate state (b) by doing "iwconfig wlan0 txpower off". If > the driver doesn't suck, the driver should then rfkill the radio (and > thus /sys/class/rfkill/rfkill0/state would be 0), but all killswitches > are still "on". But there's no way to find out that the killswitches > are all "on" by reading something in sysfs because their state is not > distinct from the radio's state. > > There are basically two options here: > > 1) separate switch state from radio state by having something on the > _device_ > like /sys/devices/pci0000:00/0000:00:1e.0/0000:02:02.0/radio_state that > is 0 (radio on), 1 (radio off, softkilled), or 2 (radio off, > hardkilled). Keep /sys/class/rfkill/rfkillX as actual killswitches as > reported by wireless drivers or by machine-specific BIOS proxy drivers > like hp-wmi, and keep the 'state' member rfkillX devices like it is now > > 2) Change the 'state' member of the /sys/class/rfkill/rfkillX devices to > reflect the hardkill and softkill > > I personally like (1) the best, because there's a clear difference > between radio state and switch state, and it would preserve > compatibility with the current rfkill system. If the userspace process > doesn't see the 'radio_state' item in sysfs for that specific wireless > device, it would fall back to using only /sys/class/rfkill/rfkill0/state > and loose the ability to handle softkill. > SW should be able to more sw radio switch regardless of hw switch so I believe it's better to have separate sysfs entry for sw and hw switch states. hw sysfs file should be read only. I agree it good to keep radio state separately as well. Third I think this patch use opposite logic as used currently in practice. RFKILL_ON means that radio is off . Thanks Tomas > Thoughts? > > Dan > > > -- > 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 > -- 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
