On Sun, Feb 12, 2017 at 6:32 PM, Liam Breck [off-list ref] wrote:

Hi Andrew,

Based on Sebastian's feedback on v1-4 of this patchset, I believe it
will go upstream. (He hasn't written anything on linux-pm since before
I posted v5 a week ago.)

Could we get your feedback on making this adaptable to the rest of the
BQ27 family? Specifically...

Is the op sequence in these functions common across the chips?

bq27xxx_battery_set_seal_state()
bq27xxx_battery_read_dm_block()
bq27xxx_battery_write_dm_block()

Should we move these constants to bq27xxx_regs[chip][name]?

/* writable registers */
#define BQ27XXX_DATA_CLASS             0x3E
#define BQ27XXX_DATA_BLOCK             0x3F
#define BQ27XXX_BLOCK_DATA             0x40
#define BQ27XXX_BLOCK_DATA_CHECKSUM    0x60
#define BQ27XXX_BLOCK_DATA_CONTROL     0x61

/* writable register inputs */
#define BQ27XXX_SET_CFGUPDATE          0x13
#define BQ27XXX_SOFT_RESET             0x42
#define BQ27XXX_SUBCLASS_STATE_NVM     82

I dug into bqtool:gauge.c. I learned a couple things which I've added
to the patch, e.g. retrieve and compare checksum after read_dm_block.

Re command ids and params, only subclass, field offsets, and unseal
key differ among chips, which I planned for. However the driver's
current 9 enumerated chips won't accommodate all the diff unseal keys.
But I shall leave that for others to solve.

Re op sequence, bqtool apparently uses set_cfgupdate for the 441 & 621
chips, but not others, whereas the 425 manual implies that it's nec.
And bqtool uses exit_cfgupdate where 425 manual indicates soft_reset.
See open/close_dm_rom (441 & 621) vs. open/close_dm_flash. We need
some guidance on that issue.

Bqtool also uses loops to poll for begin & end of cfgupdate mode, and
to retry read/write_dm_block with increasing delays. We could add that
if nec...

http://git.ti.com/bms-linux/bqtool/blobs/master/gauge.c

Thanks!