On Sat, 18 Oct 2008, Jim Paris wrote: > > Then the ones that are very nice, but are available only on fairly recent > > ThinkPad BIOSes: > > > > 4. New HKEY notifications for overtemperature on the mainboard and battery! > > > > Thanks to some official help, the driver will know when your thinkpad is > > about to melt down or go out of juice, and will warn you accordingly through > > syslog and an ACPI event (that HAL can trap and do something with). > > Has there been any effort to coordinate with the HAL guys to get this > event handled properly at the same time? From a user point of view it > often seems that the kernel and userspace components are out of sync > and giving them a heads-up could be helpful. None. I could start trying to, yes, but it is best to test the changes in the kernel first, THEN see if I can somehow get the kernel to adopt a generic interface for a certain stuff... Only after all that, should the HAL people be bothered... > > 1. EC write access will be moved from "experimental" (which it isn't!) to a > > new "dangerous" mode. And it will be documented (it isn't, right now). The > > driver will bitch on the logs, and taint the kernel when you use this > > facility for the first time > .. > > 2. I will be restricting access to all LEDs but the ThinkLight, "power" and > > "standby". > > > > One will need to jump through some loops (probably including modifying the > > kernel source code and enabling some Kconfig options) > > Seems arbitrary that a potentially dangerous operation like writing to > the EC just complains and taints, while blinking lights isn't allowed > at all without source changes. Is there a technical reason the LEDs > need to be more restricted than EC writes? There are some reasons, yes. For the LEDs: 1. The LEDs being restricted have *NO* valid known use cases unless you are doing something VERY weird and VERY specific to your thinkpad (I expect there are maybe five people doing it in the entire world and I'd actually like to know their use cases for messing with the dock/bay/battery LEDs). When you override these LEDs, you corrupt information that is related to hardware safety. That clearly cannot be allowed unless the laptop operator is aware it is taking place. Removing (and plugging) a bay or dock device while the bay or dock connector is still active can fry the hardware. In fact, Lenovo will pretty much tell you your warranty is void if they find out you did that. Ignoring battery alarms is dangerous. Plain and simple there is absolutely no way I will have anything to do with it. 2. I cannot trust distros to not enable a "LED" feature in the code "just in case someone wants to use it" if I don't make it VERY clearly a "never enable it if it is not your own personal box and you know exactly what you are doing" thing. Because once the driver is loaded with the feature enabled, it would only take some cretin writing a half-assed desktop candy that messes with the LED (or an actively malicious script) to cause trouble. The laptop operator might never notice weird things are happening until it is too late. For the EC write: 1. It has valid usercases, unlike the LEDs being restricted: debugging and trying to understand some EC feature. 2. I cannot really have it as a compile-time-only thing, because often the person I am asking to do something cannot build his own kernels, and uses a distro I am completely unfamiliar with. This is also valid for any other people who might be playing with it and asking others to test things. Otherwise, the EC write would be under the same source code lock as the LEDs. And I don't expect any distro will enable the "dangerous" mode by default, it will be *REALLY* obnoxious. Now, I don't feel too strongly about this, so if more people are of the opinion that the EC write should be locked under a compile-time Kconfig option, I will do that. -- "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
