On Sat, 08 Nov 2008, Rafael J. Wysocki wrote: > > Meanwhile, I suggest you just remove the calls to fan_suspend and fan_resume > > as a workaround. > > Speaking of which, last time I looked at fan_suspend and fan_resume, they > were hopelessly broken (I admit that was quite some time ago, though). And they still were. I have the patch fixing it, and it reworked that path entirely. Will send it soon. > IMO, fan_suspend() is not necessary at all and the only thing fan_resume() > could do is to make the kernel's data structures reflect the actual state of > the fan. There are NO kernel data structures to reflect the actual state of the fan. The fan BELONGS to the EC in the thinkpad. We don't store any crap about it in the driver, except to -track- one quirk. We query the EC for all the required data (which happens to be a single byte) every time we need the info. If the user asks us to do something, we send that to the EC and then promptly forget about it. So, I don't have to restore anything for things to just work. The "feature" was added because people who set the fan to something different than AUTO wanted it to retain the state they set across sleep, which the box won't do by itself (the DSDT resets the fan on the WAK path). OTOH, if I want to restore anything across sleep/resume, I have to store the state on sleep. But there is no way I am slowing down the fan on resume: it could be in emergency mode due to thermal conditions. -- "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 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ ibm-acpi-devel mailing list ibm-acpi-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
