Re: [patch 2/3] acpi: compal-laptop: use rfkill switch subsystem
From: Andrew Morton <akpm@linux-foundation.org>
Date: 2008-11-05 03:36:27
On Sun, 02 Nov 2008 10:13:51 +0000 Alan Jenkins [off-list ref] wrote:
Alan Jenkins wrote:quoted
allakpm@linux-foundation.org wrote:quoted
From: Cezary Jackiewicz <cezary.jackiewicz@gmail.com> Removing unnecessary attributes, use rfkill switch subsystem. It depends on the rfkill changes in net-next-2.6. [randy.dunlap@oracle.com: compal-laptop: depends on RKFILL] Signed-off-by: Cezary Jackiewicz <cezary.jackiewicz@gmail.com> Cc: Andi Kleen <redacted> Signed-off-by: Randy Dunlap <redacted> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>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.
Are all of your review issues now addressed? I don't think so. I'll put this patch on hold until we can get this sorted out.