On Thu, 12 Jun 2008 11:43:04 -0400, "Dan Williams" <dcbw@xxxxxxxxxx> said: > As you've explained it, I believe this will work IFF we take your > suggestion and add a 3rd state RADIO_SW_BLOCKED to go along with > RADIO_HW_BLOCKED and RADIO_UNBLOCKED. Now you get it why I wanted the third state instead of a separate attribute, I hope. It integrates much better on how *current* rfkill is supposed to be used. Good, I now just have to get to that email explaining switches, which I sort of managed to already do partially, if you understood the above :-) > In this system, if NM wants to softblock a wifi device for example, it > would likely just turn off the transmitter with 'SIOCSIWTXPOW', thus the Or you could also use sysfs to set the state to 0 (BLOCK). It is supposed to perform the same operation as 'SIOCSIWTXPOW' to a power of 0, as far as rfkill is concerned. Or you could, if you wanted to turn off *ALL* transmitters of the same type, issue an input layer event for rfkill-input to process. Whichever suits your application best. > wifi device itself would report it's rfkill state as RADIO_SW_BLOCKED. > NM would then be aware that it could be re-enabled at any time through > software. Yes. > If the user then hits the hardkill switch, the wifi device would report > RADIO_HW_BLOCKED, and NM would be aware that the user must unkill the > transmitter with a physical switch. Yes. > It gets a bit interesting when unrelated killswitches like hp-wmi and > thinkpad-acpi are used, because if those just softkill the radio, you > could end up in the situation where the radio itself is RADIO_UNBLOCKED > but the struct rfkill created by hp-wmi is RADIO_SW_BLOCKED if BIOS > doesn't track the actual state of the radio too. How do we fix that? It is already fixed :-) The radio itself will be RADIO_HW_BLOCKED (to use your terms). Think about it: the thinkpad-acpi and hp-wmi softswitches are not magic, they somehow rfkill the real radio devices. That "somehow" is done through an input pin in the radio device that will change state when the thinkpad-acpi/hp-wmi softswitch changes state, so the radio device driver (which has NOTHING to do with thinkpad-acpi OR hp-wmi, and doesn't even know they exist!) will report that the radio is now in state RADIO_HW_BLOCKED. So, a softswitch in one platform driver like thinkpad-acpi or hp-wmi CAN cause a separate device under control by another module (the radio itself) to see a hardswitch rfkill happening. This is fine, it is as things are supposed to work. That's why I call the current rfkill design one that hides the switch topology from its users. Which is a Good Thing, as it means it gets that much easier to write platform drivers and network drivers that use rfkill. The uglyness of the way some devices implement rfkill happens when the hardware/firmware itself kludges things by unplugging devices from the BUS when you rfkill that device. This has nothing to do with the rfkill code in the kernel, it is just how some of these things work and we cannot change that. Bluetooth and WWAN usually get this kind of treatment. There is no sane workaround that could be done for that, we will have to deal with hotplug and hotunplugging being a common operation for such devices. -- "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
