[ltp] Re: [ibm-acpi-devel] Upcoming changes to thinkpad-acpi (your chance to comment on them)

[Henrique de Moraes Holschuh]

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