On Sun, 02 Nov 2008 10:13:51 +0000 Alan Jenkins <alan-jenkins@xxxxxxxxxxxxxx> wrote: > 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. 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. -- 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
