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] [day] [month] [year] [list]
Message-ID: <20080107025054.GA6268@zarina>
Date:	Mon, 7 Jan 2008 05:50:54 +0300
From:	Anton Vorontsov <cbouatmailru@...il.com>
To:	Dmitry Baryshkov <dbaryshkov@...il.com>
Cc:	linux-kernel@...r.kernel.org, cbou@...l.ru, dwmw2@...radead.org
Subject: Re: [PATCH 3/3] apm_power: Support using VOLTAGE_* properties for
	apm calculations

On Sun, Jan 06, 2008 at 03:30:16PM +0300, Dmitry Baryshkov wrote:
> Support using VOLTAGE_* properties for apm calculations. It's pretty
> dummy, but useful for batteries for which we can only get voltages.

By the way...

> diff --git a/drivers/power/apm_power.c b/drivers/power/apm_power.c
> index bbf3ee1..526c96e 100644
> --- a/drivers/power/apm_power.c
> +++ b/drivers/power/apm_power.c
[...]
> -static int calculate_time(int status, int using_charge)
> +static int calculate_time(int status, apm_source source)
[...]
> +	case SOURCE_VOLTAGE:
> +		full_prop = POWER_SUPPLY_PROP_VOLTAGE_MAX;
> +		full_design_prop = POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN;
> +		empty_prop = POWER_SUPPLY_PROP_VOLTAGE_MIN;
> +		empty_design_prop = POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN;
> +		cur_avg_prop = POWER_SUPPLY_PROP_VOLTAGE_AVG;
> +		cur_now_prop = POWER_SUPPLY_PROP_VOLTAGE_NOW;
> +		break;
[...]
>  		return -((cur.intval - empty.intval) * 60L) / I.intval;

This formula will return nonsense if you'll feed it with voltage:
Ohms * 60 minutes? ;-)

I'd suppose you can get better accuracy if you'll divide it by
some constant (resistance, we can define new property for it),
but I still doubt it, because this formula doesn't work good
enough even for batteries reporting charge. ;-)

It's interesting what actual values you're getting and how they
accurate.

There is another option though: if you know battery charge
full/empty thresholds (usually you know design values, they
should be written on the battery pack), then you can use this
formula to calculate "charge_now":

((voltage_now - voltage_min) * (charge_full - charge_empty)) /
(voltage_max - voltage_min)

And then you can calculate time as usual, using
charge_{now,full,empty} and current_now. But still, this is
very inaccurate, there isn't direct correlation between
charge and voltage. Oh well, power_supply_class.txt already
states about apm_power.c limitations.


So, with few cosmetic corrections I applied all your patches to
git://git.infradead.org/battery-2.6.git

I also applied few my patches I sent here earlier, hope they
don't break anything (at least they survived my tests).

Good luck,

-- 
Anton Vorontsov
email: cbou@...l.ru
backup email: ya-cbou@...dex.ru
irc://irc.freenode.net/bd2
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ