linux-kernel - Re: [PATCH 07/14 v3] bq27x00: Cache battery registers

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: <4D59A93A.7090800@metafoo.de>
Date:	Mon, 14 Feb 2011 23:14:18 +0100
From:	Lars-Peter Clausen <lars@...afoo.de>
To:	Grazvydas Ignotas <notasas@...il.com>
CC:	Anton Vorontsov <cbouatmailru@...il.com>,
	Pali Rohar <pali.rohar@...il.com>,
	Rodolfo Giometti <giometti@...ux.it>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 07/14 v3] bq27x00: Cache battery registers

On 02/14/2011 10:58 PM, Grazvydas Ignotas wrote:
> On Mon, Feb 14, 2011 at 5:01 AM, Lars-Peter Clausen <lars@...afoo.de> wrote:
>> This patch adds a register cache to the bq27x00 battery driver.
>> Usually multiple, if not all, power_supply properties are queried at once,
>> for example when an uevent is generated. Since some registers are used by
>> multiple properties caching the registers should reduce the number of
>> reads.
>>
>> The cache is valid for 5 seconds this roughly matches the internal update
>> interval of the current register for the bq27000/bq27200.
>>
>> Fast changing properties(*_NOW) which can be obtained by reading a single
>> register are not cached.
>>
>> It will also be used in the follow up patch to check if the battery status
>> has been changed since the last update to emit power_supply_changed events.
>>
>> Signed-off-by: Lars-Peter Clausen <lars@...afoo.de>
>> ---
>>  drivers/power/bq27x00_battery.c |  271 +++++++++++++++++++++-----------------
>>  1 files changed, 150 insertions(+), 121 deletions(-)
>>
>> diff --git a/drivers/power/bq27x00_battery.c b/drivers/power/bq27x00_battery.c
>> index 44bc76b..dbe3fcb 100644
>> --- a/drivers/power/bq27x00_battery.c
>> +++ b/drivers/power/bq27x00_battery.c
> 
> <snip>
> 
>> -static int bq27x00_battery_current(struct bq27x00_device_info *di)
>> +static int bq27x00_battery_current(struct bq27x00_device_info *di,
>> +       union power_supply_propval *val)
>>  {
>> -       int ret;
>> -       int curr = 0;
>> -       int flags = 0;
>> +       int curr;
>>
>> -       ret = bq27x00_read(di, BQ27x00_REG_AI, &curr, false);
>> -       if (ret) {
>> -               dev_err(di->dev, "error reading current\n");
>> -               return 0;
>> -       }
>> +       if (di->chip == BQ27500)
>> +           curr = bq27x00_read(di, BQ27x00_REG_AI, false);
>> +       else
>> +           curr = di->cache.current_now;
>> +
>> +       if (curr < 0)
>> +               return curr;
> 
> This is wrong, as read function returns negative values for bq27500
> when discharging. That's why read function used to pass value through
> argument before your series (return value was for error code).

I don't think so. The register is 16bit wide and it is read as a unsigned. So
in the non error case bq27x00_read will always return >= 0.
The value is later reinterpreted as a signed 16bit.(See the other lines you
quoted underneath).

Did you experience any actual problem with current being wrong?

> 
> Sorry for not noticing this earlier, I only found this now during testing.
> 
>>
>>        if (di->chip == BQ27500) {
>>                /* bq27500 returns signed value */
>> -               curr = (int)((s16)curr) * 1000;
>> +               val->intval = (int)((s16)curr) * 1000;

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