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]

Message-ID: <A6D19A13FE030A409EC4362C172E091F0E071EB9@eseldmw101.eemea.ericsson.se>
Date:	Sat, 5 Dec 2009 14:08:11 +0100
From:	"Linus Walleij" <linus.walleij@...ricsson.com>
To:	"Mark Brown" <broonie@...nsource.wolfsonmicro.com>
Cc:	<cbou@....ru>, <dwmw2@...radead.org>,
	"LKML" <linux-kernel@...r.kernel.org>,
	<linux-embedded@...r.kernel.org>
Subject: RE: [POWER] battery calibration parameters from sysfs

Thanks Mark, prompt answers as always.

[Mark Brown]
> [Linus Walleij]
> > In our code we have a number of (x,y) pair tables like this:
> 
> > /* Vbat mV to Battery capacity % */
> > struct voltage_vs_capacity {
> > 	int voltage;
> > 	int capacity;
> > };
> 
> Isn't the standard thing here to handle this voltage to 
> capacity mapping in userspace if we're just extrapolating
> from experimental results?

That's an easy solution of course, but then the sysfs files
specified by the power subsystem, i.e. all "charge_*",
"energy_*", "capacity" and "time_to_*" loose their meaning
and must be ignored by userspace.

Also this was just an example, we have similar calibration
for the temperature sensor, and thus the "temp" sysfs file
also loose its meaning.

Since there is a plethora of userspace apps that just
interface these files directly (gnome-power-manager and
the Android stack come to mind) all these will have to
be patches to accept a calibrated value from somewhere
else if we shall use them with our hardware.

But as you say:

> Even with the "smart" batteries in PCs there are some 
> accuracy concerns and obviously the performance of the
> battery will change over time.
> ...
> Actually, one further thing here - if this functionality
> is implemented in kernel then shouldn't it be a generic
> feature rather than part of the driver?  The idea of
> mapping battery voltages to capacity percentages isn't
> specific to a given charger and will apply to all
> batteries using the same technology.

Surely, we'd be happy to do it that way if desired.
What about drivers/power/battery_lib.c?

(And getting algorithms in place for gradually
adjusting the capacity levels as compared to factory
settings for PC batteries would perhaps end up in the
same place then.)

We have other odd code. Actually we have full software-
controlled CC/CV charging in our driver, and that
would *definately* go in such a library if it was
to end up in kernelspace. We have actually
pushed that to userspace, while I still tend to think
that the kernel (with right parameters) should be able
to charge a battery. But, well.

As for the calibration format, after reading up on the
latest sysfs doc I saw:

Documentation/filesystems/sysfs.txt:
"Attributes should be ASCII text files, preferably with
only one value per file. It is noted that it may not be
efficient to contain only one value per file, so it is
socially acceptable to express an array of values of the
same type."

This is close to that, an array of two types (x,y)(x,y)
voltage,capacity,voltage,capacity etc. Pushing them in
two files

/sys/.../v_vs_cap_v
/sys/.../v_vs_cap_cap

and then make sure we write as many values to each array
is uglier IMHO.

Yours,
Linus Walleij
--
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/