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: <1154604546.4302.482.camel@queen.suse.de>
Date:	Thu, 03 Aug 2006 13:29:06 +0200
From:	Thomas Renninger <trenn@...e.de>
To:	Jean Delvare <khali@...ux-fr.org>
Cc:	Pavel Machek <pavel@...e.cz>,
	Shem Multinymous <multinymous@...il.com>,
	Vojtech Pavlik <vojtech@...e.cz>,
	"Brown, Len" <len.brown@...el.com>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	kernel list <linux-kernel@...r.kernel.org>,
	linux-thinkpad@...ux-thinkpad.org, linux-acpi@...r.kernel.org,
	Henrique de Moraes Holschuh <hmh@...ian.org>,
	Mark Underwood <basicmark@...oo.com>, Greg KH <greg@...ah.com>
Subject: Re: Generic battery interface

On Wed, 2006-08-02 at 09:18 +0200, Jean Delvare wrote:
> Hi Pavel,
> 
> > > frequently it can read from the chip. And no hardware monitoring chip I
> > > know of can tell when the monitored value has changed - you have to read
> > > the chip registers to know.
> > 
> > ACPI battery can tell when values change in significant way. (Like
> > battery becoming critical).
> 
> Ah, good to know. But is there a practical use for this? I'd suspect
> that the user wants to know the battery charge% all the time anyway,
> critical or not.

Some batteries throw an event for each consumed percent or at least
enough events to keep track of remaining power.
Some are only throwing an event when capacity warning/low is reached,
some aren't throwing any events.

It may be of use to reduce polling on some machines, but you will always
need a fall back. Determining whether the machine throws events
regularly is not really possible, so by default you will start to poll
the battery on all machines. Maybe in this case the normal (0x80)
battery events should be ignored to avoid double readings or the values
are cached in kernel as suggested, then it does not hurt.

One should also not rely on the warning/low capacity values.
I cannot say for sure whether all machines throw an event if these
limits are reached. We defined our own limits in userspace, this always
works. I'd go for not using the BIOS limits here at all and take user
defined capacity warning/low values (in percent) in hal or wherever.

IMO opinion the normal battery events (0x80) are not much of a use. They
probably should be forwarded, so that userspace could switch to irq
driven notification if this should ever work on more than 90% of the
machines, but default will be polling. More important are the status
events (0x81) if a battery is added/removed.

   Thomas

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