linux-kernel - Re: [POWER] battery calibration parameters from sysfs

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]

Date:	Mon, 7 Dec 2009 21:27:20 -0800
From:	Brian Swetland <swetland@...gle.com>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Rebecca Schultz Zavin <rebecca@...roid.com>,
	Mike Lockwood <lockwood@...roid.com>
Cc:	Linus Walleij <linus.walleij@...ricsson.com>, cbou@...l.ru,
	dwmw2@...radead.org, LKML <linux-kernel@...r.kernel.org>,
	linux-embedded@...r.kernel.org
Subject: Re: [POWER] battery calibration parameters from sysfs

On Mon, Dec 7, 2009 at 8:56 AM, Mark Brown
<broonie@...nsource.wolfsonmicro.com> wrote:
>
>> One of the things we're facing is Android, which has
>> its userspace in plain Java JNI at the end of this link:
>> http://android.git.kernel.org/?p=platform/frameworks/base.git;a=blob;f=s
>> ervices/jni/com_android_server_BatteryService.cpp;h=8e7cadc6b680fc420d34
>> 1faa094c71922946fdab;hb=HEAD
>
> Something word wrapped that link but I think I found the same code.
>
>> If you browse down to line 275 you can see it parse the sysfs
>> attribute "capacity", then this propagates up to the battery
>> status indicator on *all* Android phones out there. So if
>> you want to run Android unmodified, this is what you need to
>> provide. They are effectively using the power sysfs as
>> their hardware abstraction layer in this case.
>
> Oh dear.  Using the power sysfs as the hardware abstraction seems
> perfectly reasonable but assuming that a given battery driver is going
> to have this level of information doesn't match up with an awful lot of
> actual charger hardware.  My main concern here is that battery
> performance monitoring has no pressing need to be in kernel and that
> pushing it into the kernel creates a barrier to implementing more
> advanced schemes in userspace, which is especially serious given how
> involved this needs to be in order to be accurate.

We should tidy up the userspace side to have better abstraction for
this.  On a number of devices we do obtain all the information
necessary from the kernel driver (or, in some cases battery monitoring
on the baseband side that the kernel driver chats with).  On other
devices we don't (Motorola Droid, for example uses a userspace battery
daemon).

>> Note: I'm not claiming that Android is doing it right or that
>> we can't modify this code or so, it's just that this is the way
>> a few million Android devices out there are actually doing it.
>
> I don't think the existing Android devices are much of an issue here,
> it's not as though end users have the ability modify the firmware on
> them (modulo the fairly small number of ADP devices).  This is an issue
> for people producing new devices who are already going to be doing some
> development to get the kernel up and running on their hardware.

My preference, from an Android point of view, would be to make sure we
have some reasonable userspace abstraction and provide a default
implementation that will do the right thing with an intelligent
battery driver (our usual design for inhouse work).  Then alternative
implementations can be plugged in, should that not be sufficient.

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