linux-kernel - Re: Generic battery interface

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <41840b750607270739u7b6fe7efl5ac5ec147d83e624@mail.gmail.com>
Date:	Thu, 27 Jul 2006 17:39:06 +0300
From:	"Shem Multinymous" <multinymous@...il.com>
To:	"Matthew Garrett" <mjg59@...f.ucam.org>
Cc:	"Pavel Machek" <pavel@...e.cz>, vojtech@...e.cz,
	"Len Brown" <len.brown@...el.com>,
	"kernel list" <linux-kernel@...r.kernel.org>,
	linux-thinkpad@...ux-thinkpad.org
Subject: Re: Generic battery interface

On 7/27/06, Matthew Garrett <mjg59@...f.ucam.org> wrote:
> 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?

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 http://thinkwiki.org/wiki/tp_smapi for detials).

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.

So, if we insist on a standard battery device class name, how do we
cope with multiple sources of information and control functions?

  Shem
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/