On Fri, 31 Oct 2008, Alan Jenkins wrote: > > Documentation/rfkill.txt implied otherwise Then we need to make it more clear. > > You should: > > - rfkill_allocate() > > - modify rfkill fields (flags, name) > > - modify state to the current hardware state (THIS IS THE ONLY TIME > > YOU CAN ACCESS state DIRECTLY) > > - rfkill_register() At which point rfkill core will KICK your device to the state it wants it to be, so if you lied on the state, you are screwed. I mean it. You want rfkill_set_default(), and only because it is a platform driver storing state across shutdown. > > Admittedly it doesn't say "and I promise not to gratuitously override > > the state on registration". Buti t seems weird though, to override the > > value on registration No, it is EXACTLY what it should do. It is setting policy for a class of switches (actually, controllers. Call it a switch and you confuse it with input devices). It is not "enabling the radio" by default, it is setting the radio rfkill controllers to the same state that all other rfkill controllers on radios of that type currently are at. And there is rfkill_set_default() for *platform* drivers to influence that, when the platform has a better idea of the proper initial radio rfkill state. > Ah, I see. Wrong end - of course the *rfkill device* doesn't have > useful state. The persistent state belongs to the *rfkill switch* - it > could even be a physical switch. Of course it has useful state. Set it to whatever the rfkill controller state really IS at that point. And it HAS persistent state, but the core will govern it to match the system-wide policy. > And now it's clear what was missing from the conversion to rfkill: > > 2. Input device switches (sources of EV_SW events) DO store their > current state > (so you *must* initialize it by issuing a gratuitous input layer > event on > driver start-up and also when resuming from sleep) No. You *ARE* to send gratuitous input layer events for SWITCHES quite often, e.g. on every call to the switche's connect() handler, and also often after system-wide stuff like resume (when state could have changed without you being able to notice it) because you *HAVE* to tell the input layer which is the initial/real state of the switch. If this is not clear, the input layer needs some doc tweaking. Please feel free to send a patch to Dmitry. But that has nothing to do with the rfkill core. You MUST NEVER try to change rfkill core state through the input layer from inside the kernel. NEVER. rfkill_input is NOT part of the rfkill core, and rfkill_input is the ONLY thing that cares about input events that match one of the "rfkill" input events. And it *is* optional. -- "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-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
