Re: Generic battery interface

From: Pavel Machek
Date: Thu Jul 27 2006 - 10:57:56 EST


> >This would also be useful for the OLPC project - it's unlikely that
> >it'll use ACPI, but a more feature-rich interface than /proc/apm would
> >be massively helpful. This is just a matter of speccing out what
> >information is needed and what format it should be presented in, and
> >then adding a new device class, right?
> Can we really assume there's one driver providing all battery-related
> attributes?

Anything else would be crazy, I'd say.

> For example, on a ThinkPad you want the ACPI battery module loaded so
> that handles hande battery-related ACPI events, but on ACPI can't
> doesn't provide all available attributes. For example, ACPI reports
> the equvialent of
> /sys/devices/platform/smapi/BAT0/power_avg (last minute average)
> but not
> /sys/devices/platform/smapi/BAT0/power_now (instantaneous average)
> or
> /sys/devices/platform/smapi/BAT0/cycle_count
> or control functions like
> /sys/devices/platform/smapi/BAT0/force_discharge
> (see for detials).

Well, in that case probably smapi driver should "hook into" acpi

> In this particular case we could split the ACPI module into two, one
> module for events and one module for the sysfs interface, and load
> only the first one on ThinkPads. But that's only because tp_smapi
> happens to reproduce all of ACPI's attributes; there are probably
> other cases whether neither method dominates the other.

I hope such hardware will not be too common. Thinkpad is covered by
accident, and I do not know about any other problematic machine.

Worst case, we would get equivalent of


with some values common between both of them. I'd say it is still
better than having vendor_hack in /sys in one format while having acpi
battery in /proc/acpi in completely different format.
(cesky, pictures)
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at