Matthew Garrett wrote:
On Sun, Nov 02, 2008 at 11:17:34AM +0000, Alan Jenkins wrote:
Did you have any thoughts on the hibernation case? It's possible for the
rfkill state to change while hibernated. You can boot into a different
OS, or change it in the BIOS setup screen. At present the rfkill core
overrides the change on resume.
There are two choices. We can either set the rfkill to the hardware
state, or we can set the hardware state to the rfkill state. I think
both are valid choices and I'm happy to implement either of them in the
resume path. However, as you point out, right now it's possible for the
user to change the hardware state in the BIOS and cause the two to get
out of sync. That's certainly not ideal.
No, the current rfkill core forces the device to restore the state on
resume. So it can't be of sync after resume. And there's no way for
the platform driver to affect this behaviour, aside from illegally
generating input events.
If we want resume from hibernation to preserve the hardware state
instead of overriding it, the rfkill API needs changing. I'm not sure
how that can be justified, given how obscure it is as a use-case, and
the damage it would do to an API which already, uh, seems to be
frequently misunderstood.
Regards
Alan
--
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
