On Sat, 28 Nov 2009, Alan Jenkins wrote: > Sorry for my naff patch description. The actual corner case is when > the soft rfkill state changes between when we suspend and resume. Ah, ok. > "we really want to restore the hardware to the previous soft state" > > Context warning: this only affects "persistent" rfkill devices. We > currently do this for everything except thinkpad-acpi and > eeepc-laptop. Yes. This is _only_ about persistent rfkill devices, i.e. thinkpads and eeepc. > Blame Marcel, the current choice was his suggestion :). I think his > argument was that restoring the state could impose policy, and that > this would be bad. I didn't resist too hard because his principle > provides a marginal feature in eeepc-laptop. Actually, that is a good argument, and I was not aware of it. > [That said, I later noticed that it speeds up resume from s2ram. > eeepc-laptop is 'special'; its WLDS method takes a whole second to > run.] Which is another good argument. I can fix the regression in thinkpad-acpi either way, and I have just found that I _will_ have to change code in thinkpad-acpi to fix it in either case. But I'd rather do it in the best way possible :) If the current way (no resume for persistent devices) has real advantages, I will just deal with it in the driver. > To elaborate: > > The state in NV-ram may be changed deliberately. On eeepc-laptop, > you can change it in the BIOS setup screen - and then resume from > hibernation. Marcel suggests that overriding this change would be a > policy decision, which userspace should be able to control. The > simplest way to do so is to simply preserve the state (and emit an > event to notify userspace of the change). I see. that's the missing link. While thinkpads _can_ do that too, it changes the *hard* kill line, and it (obviously) cannot be overriden at all... When you disable radios in the ThinkPad BIOS, they _stay_ disabled... at least on the IBM models. I was aware of the change-in-NVRAM possibility, but dismissed it since we don't support booting another OS in the middle of a hibernation cycle. The idea that the BIOS could be used to change NVRAM didn't cross my mind. > I thought thinkpad-acpi might also allow such changes. At least for > some controls, the BIOS defaults to implementing them itself, right? Yes, but for the radios, the BIOS goes the way of "disabled is disabled", and doesn't let you change the NVRAM. That might have changed on the newer Lenovo models, but I have not heard of any changes yet. > Even if this isn't true for rfkill on the thinkpad, it's a > possibility we may encounter in future. Imagine a system where this You told me EEEPC takes good advantage of the current way of doing things, and I can certainly make it work properly in thinkpad-acpi as well. So, as far as I am concerned, you proved to me that there are strong advantages for the current way of doing things, and until there is a compelling need to have radios locked on resume, I think it is best to leave things as is. > - hibernate > - boot resume kernel > - user presses rfkill key -> BIOS toggles the rfkill state > - load kernel from hibernation image > - rfkill resume now unconditionally overrides the rfkill state Yeah, ugly mess. > rfkill-input is scheduled for removal in anticipation of rfkilld. If > you want to schedule removal of persistent rfkill devices in > anticipation of "rfkilld with persistence", that would seem just as > reasonable :-p. I'm sure Johannes would then accept the small change > to the rfkill core to fix this regression. Nah, I think it is best to deal it in the driver, given the data you just presented. And I am strongly against foring users to use rfkilld-based persistence in platforms that can do better (i.e. thinkpad-acpi and eeepc) :-) -- "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
