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

[Henrique de Moraes Holschuh]

On Sun, 19 Oct 2008, Matthew Garrett wrote:
> On Sat, Oct 18, 2008 at 11:34:57AM -0300, Henrique de Moraes Holschuh wrote:
> > 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).
> 
> Mm. Register a generic thermal class device and then generate a uevent? 
> It'd be nice to do this in a generic "something has just gone wrong" 
> way, which we could then also do for critical notifications in ACPI 
> thermal zones.

Agreed. Let's take this to linux-acpi, then. I will prepare an initial patch
that just printk() warnings, so that we get something usable right away.
The thinkpad-specific events are sent to userspace already.  I can filter
them out later when we get the generic interface.

> > Again, thanks to that unnamed official help!  I am still not sure what I can
> > do besides logging an alarm and issuing an ACPI event... and I really want
> > to do something, as it is doubtful there will be anyone around to listen to
> > the kernel cries if the machine woke up almost out-of-battery.
> 
> We need decent infrastructure for exposing the reason for the wakeup - 
> ACPI can also provide this under various circumstances, but right now we 
> don't seem to do anything terribly useful with it. What will basically 
> happen now is that the machine will wake up, userspace will (with luck) 
> notice that the power is critical and either do a hibernation or clean 
> shutdown. The wakeup event is bonus information.

Looks like something to take to linux-acpi as well. We do need generic
events for this sort of thing.

Thinkpads know these:
1. Wakeup because bay has requested an eject (and also if from S3 or S4).
   (and there is an event when the eject is complete, which could be
   used to go back to sleep).
   * as usual, one can notify the user to NOT complete the operation,
     because resources could not be properly freed, such as due to
     filesystems in use
2. Wakeup because dock has requested an eject (same as (1) above)
3. Wakeup because the battery is critically low (also if from S3 or S4).
   * New BIOSes only.

And for thermal, these (only on new BIOSes):
1. Thermal sensor(s) in warning level (notify the user)
2. Thermal sensor(s) in critical level (O.S. should attempt to enter S3
   IMMEDIATELY)
3. Battery sensor in warning temperature level (notify the user)
4. Battery sensor in critical temperature level (same as (2)).

-- 
  "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