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]

Date:	Tue, 15 Feb 2011 13:48:28 +0200
From:	Grazvydas Ignotas <notasas@...il.com>
To:	Lars-Peter Clausen <lars@...afoo.de>
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 Tue, Feb 15, 2011 at 12:14 AM, Lars-Peter Clausen <lars@...afoo.de> wrote:
> 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:
>>>
>>> -       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).

Hmh, right..

> Did you experience any actual problem with current being wrong?

Yes, the returned current values were randomly jumping between -500000
and 600000 while the device was discharging, so I thought
uninitialized values were being returned (this never happened before
the series; no errors in dmesg). I'll need to debug a bit more I
guess..
--
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/