On Mon, 03 Nov 2008, Matthew Garrett wrote: > On Mon, Nov 03, 2008 at 12:51:45PM -0200, Henrique de Moraes Holschuh wrote: > > Not if you can enter or exit HARD_BLOCK, you're not. If you cannot it is > > fine. But if you can, you really need to rfkill_force_state() on resume, > > The state can always be overridden by software, so I think we're fine > there. The only things that can go out of HARD_BLOCK are rfkill_force_state() or a call to get_state(), which will only happen much later (not during the resume process). > > And the rfkill core seems to be buggy when you call force_state() on resume, > > which you guys didn't hit because you're not doing it yet. See my other > > email... > > Just to make sure: in the case where we *don't* support hard blocking, > there's no need to do anything special in the driver on resume and > rfkill should (but currently doesn't) do the right thing itself? Right now, you should still rfkill_force_state(). Please wait for an hour or two while I clean up that broken resume handling, and I will tell you for sure. Chances are I can "un-optimize" rfkill_toggle_radio to always use get_state(), and then your answer will be "yes, you don't need to rfkill_force_state() ever if you don't support HARD_BLOCK". Note that only using get_state() is NOT good for the user interface if the firmware or hardware can change the rfkill state of the device. -- "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
