From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Andrew F. Davis" Subject: Re: [PATCH] power: bq27xxx_battery: Unique chip IDs Date: Wed, 8 Mar 2017 11:58:52 -0600 Message-ID: <739da500-67dc-ec2e-f790-e68855c31594@ti.com> References: <20170307230536.22886-1-liam@networkimprov.net> <0088f5a9-995e-bc57-6fa1-3c8991287a13@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Return-path: Received: from fllnx209.ext.ti.com ([198.47.19.16]:37513 "EHLO fllnx209.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753027AbdCHR7V (ORCPT ); Wed, 8 Mar 2017 12:59:21 -0500 In-Reply-To: Sender: linux-pm-owner@vger.kernel.org List-Id: linux-pm@vger.kernel.org To: Liam Breck Cc: linux-pm@vger.kernel.org, Liam Breck On 03/08/2017 11:45 AM, Liam Breck wrote: > On Wed, Mar 8, 2017 at 9:23 AM, Andrew F. Davis wrote: >> On 03/07/2017 05:05 PM, Liam Breck wrote: >>> From: Liam Breck >>> >>> Assign every chip a unique ID, to enable >>> power_supply_battery_info config for all supported chips. >>> There are no functional changes to the driver. >>> >>> Depends-on: power: bq27xxx_battery: Add power_supply_battery_info support >>> Signed-off-by: Liam Breck >>> >>> --- >>> Andrew, let me know if you'd like me to include this in the other patchset. >> >> Why do we need this at all? It may be just bit too early for me, but I'm >> not seeing what this gets us, that couldn't be done before. > > Sadly, the chips mostly have different dm_reg tables, so we need the > real chip ID to give each a table. > > My last rev only supported IDs associated with a single chip: 500, > 545, 421. In the 421 case, we had to split off that ID. > Okay, then if we need a new ID lets add it. Going back to having a table of pointers is a step back, we used to do it this way, but every-time a new chip appeared or we found a delta in an existing chip(s) (like you are finding now) we would have to re-organize the pointer table and other associated tables, it is much cleaner and easier to review (more important than code size by orders of magnitude IMHO) to just add a new entry into the big master table of registers. > >>> drivers/power/supply/bq27xxx_battery.c | 94 +++++++++++++++++------------- >>> drivers/power/supply/bq27xxx_battery_i2c.c | 14 ++--- >>> include/linux/power/bq27xxx_battery.h | 15 +++-- >>> 3 files changed, 71 insertions(+), 52 deletions(-) >>> >>> diff --git a/drivers/power/supply/bq27xxx_battery.c b/drivers/power/supply/bq27xxx_battery.c >>> index ed976a1..30af0e4 100644 >>> --- a/drivers/power/supply/bq27xxx_battery.c >>> +++ b/drivers/power/supply/bq27xxx_battery.c > >>> +static u8* bq27xxx_regs[] = { >>> + [BQ27000] = bq27000_regs, /* really bq27200 */ >>> + [BQ27010] = bq27010_regs, /* really bq27210 */ >> >> Not strictly true, the bq270x0 and bq272x0 are different chips, one has >> an HDQ bus and the other I2C, later chips have both ports on each chip. > > Oh, I saw only the 200 & 210 in _i2c.c, and forgot that the driver > supports another interface. I'll remove those comments. > > I won't separate these IDs as none of them support DM update. > > Think you could do some testing soon? > Yeah, I could probably fit some testing into my schedule, I'll see what v9 looks like before I unpack the boards.