(adding lm-sensors to the cc list) On Thu, 03 May 2007, Thomas Renninger wrote: > I didn't have a closer look to the fan watchdog, but it looks like a > ThinkPad specific thing? The fan watchdog could be generic and done for any driver that knows how to set a fan to a default, "safe" state even during a temperature-zone- is-critical situation (i.e. the driver must know enough to never slow down a fan that has been kicked into emergency mode, if a fan watchdog functionality is to be safe). The hwmon interface and sysfs glue could indeed be generic, and need just one callback to the driver-specific code. If a fan control chip or firmware can do it in hardware, the callback programs the hardware. If it is done in software by the driver, the callback schedules the watchdog task. > IMO we could need some general fan watchdog as fans are breaking away > here and there. > Latest reports came from HPs and FSC models ... It won't help if the breakage is due to the driver not being able to communicate with the fan properly, but it would help very much so if it is caused by something else that keeps turning the fan off. I don't know how well it would work with a generic ACPI framework for fans, given that the ACPI control model for fans is braindead (no fan speed control or tachometer reading support -- that was an extreme oversight) and not really trustable in the last crop of crap the laptop vendors are pushing out as DSDTs. We'd need a rearming watchdog for what you want, though. The one I added for thinkpad-acpi/ibm-acpi is a single-fire one that doesn't rearm, as it targets userspace fan control applications that die or get stuck (userspace fan control applications *are* quite popular in T4x ThinkPads both in Linux and Windows). It would be simple enough to add a "fan_watchdog_rearm" attribute that is set to either zero (don't rearm) or one (rearm), and that is less confusing than, e.g. using negative numbers for one sort of watchdog and positive numbers for the other sort. > A check whether the fan/power resource is still in the assumed state > or whether something changed it behind the back is a general good idea? That is a future feature I was thinking about adding to thinkpad-acpi, so I vote yes for machines in which we can trust the firmware. It would easily belly-flop the kind of crap people are delivering on laptop DSDTs nowadays, though... -- "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
