On Wed, 02 Dec 2009, Jerone Young wrote: > Thanks Henrique! I havn't had time to get back to debugging this issue > since initially trying to go after it. > > Very curious on the fix. I rember diggin though the code and I can image > it's not an obvious bug just looking at the code. Basically, the new rfkill core (for good reasons, to the benefit of the EeePC driver) will not do a class resume on persistent devices. So, thinkpad-acpi has to do it itself. I took the easy way out: asked the firmware to do it for us. So far, the only oddity reported is that if the user switches the hardware rfkill switch off then on, the firmware will resume with all radios unblocked. I *can* work around that, by ignoring the firmware entirely on a suspend/resume cycle. I am not convinced this is would be a better choice. -- "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 ------------------------------------------------------------------------------ Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev _______________________________________________ ibm-acpi-devel mailing list ibm-acpi-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
