Alan Jenkins wrote:
allakpm@xxxxxxxxxxxxxxxxxxxx wrote:
From: Cezary Jackiewicz <cezary.jackiewicz@xxxxxxxxx>
Removing unnecessary attributes, use rfkill switch subsystem.
It depends on the rfkill changes in net-next-2.6.
[randy.dunlap@xxxxxxxxxx: compal-laptop: depends on RKFILL]
Signed-off-by: Cezary Jackiewicz <cezary.jackiewicz@xxxxxxxxx>
Cc: Andi Kleen <andi@xxxxxxxxxxxxxx>
Signed-off-by: Randy Dunlap <randy.dunlap@xxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
Having read rfkill.txt and tested the rfkill conversion for eeepc-laptop,
I have a few queries about this one. I hope they are useful.
Firstly, does the hardware preserve the rfkill state over power-off / reboot,
like the EeePC?
If it does, I think rfkill.txt says you need to generate "gratuitous"
input events on init. That would allow rfkill_input to initialize
the system rfkill state from the hardware. You should also do so on resume,
in case someone hibernates, boots into another OS, changes the state, and then
resumes back into Linux.
Otherwise, the system rfkill state will default to enabled on boot,
and your rfkill device will be set accordingly. If compal-laptop
used to preserve the state, I think this would be a regression.
Scratch that, I've been re-educated by Herique. If the platform does
make the rfkill state persistent, you should call rfkill_set_default()
at load-time, before rfkill_allocate / _register.
--
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
