linux-kernel - Re: BQ27xxx 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:   Thu, 22 Dec 2016 10:37:56 +1100
From:   Chris Lapa <chris@...a.com.au>
To:     Pali Rohár <pali.rohar@...il.com>
Cc:     afd@...com, Sebastian Reichel <sre@...nel.org>,
        linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: BQ27xxx registers

On 21/12/16 11:46 pm, Pali Rohár wrote:
> On Wednesday 21 December 2016 03:49:10 Chris Lapa wrote:
>> On 20/12/16 10:34 pm, Pali Rohár wrote:
>>> On Tuesday 20 December 2016 07:00:41 Chris Lapa wrote:
>>>> I can generate a patch to fix this issue, however the bigger
>>>> problem exists as to which revision fuel gauge the
>>>> bq27xxx_battery.c driver is intended to support for each family.
>>>
>>> Hi! I think driver should support all revisions. There can be (and
>>> probably really is) hardware which uses old revision and such
>>> hardware should be still supported...
>>
>> I agree. However due to the register address changes across the
>> spectrum of revisions, each revision will have to be specified
>> individually. For example, we will need to implement a BQ27510G1,
>> BQ27510G2, BQ27510G3, BQ27520G1, BQ27520G2, BQ27520G3, BQ27520G4
>> definitions and prospective device tree additions ti,bq27510g1,
>> ti,bq27510g2 etc.
>>
>> The other option is to aim for bottom of the barrel support for all
>> the devices under the BQ27500 definition but my feeling is it would
>> get messier fast and be less maintainable.
>>
>> My preference is to go with the first option if you agree?
>
> Yes. If those chips have different register addresses, then those chips
> are different. Name, generation or suffix does not matter here.
>
> Similarly there could be chips with different name, but same addresses,
> so can use one driver/configuration without any change.
>
> So I'm for different name in device tree (or platform data or what is
> being used) to distinguish between different revisions.
>

I've been working my way through the revision migration datasheets and 
noticed this could be simplified with the FW_VERSION parameter. It is 
always located at the same address and is distinctly different between 
each chip revision. Unfortunately the migration datasheets vs individual 
revision datasheets firmware version information directly contradict 
each other. Which makes me wary of committing to using it.

Given that I don't have every single variant of this device to test 
with, its probably still safest to have the user manually specify each 
device. I should have some patches ready soon.

Thanks,
Chris