Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp851243imm; Fri, 1 Jun 2018 10:35:24 -0700 (PDT) X-Google-Smtp-Source: ADUXVKLsQhWQuCY7h7NGGZoOtQi1a99rFeuA6NR9JxukOmbwmIidloHIIcSbHIfvKOQ6sKASdHgc X-Received: by 2002:a17:902:4203:: with SMTP id g3-v6mr12279013pld.315.1527874524031; Fri, 01 Jun 2018 10:35:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527874523; cv=none; d=google.com; s=arc-20160816; b=MQjIaj/2dHXBZbzAaVrfEUGWUBTA7+Qv09K+lmG40BMtgBW8LTmbOgjuJBkWsapzGg h64Pyx47ZTOPyh/HswZZz98OdbaD/EgQyvgPbO/QyMP9BHPgxnA3Sr7lkgmHUnw+dTcj gK/9NBewbZF9LhPhdr7WidQvY1je61REt7QXvnpGzdXP8V0NNy7S3V7X6y48z+OevZmX jhLsQ/HNMWMUlDMPKXCGxhXDuOWq5vESHJmLbFwuYcR79mGdjQv8g59cfgFbVXMviUWE rXkrIWg01Cy7ogggWQtlsRNdjqIgIHQ8lboCmox1GhqrNvSKK6yTvSonNzwmok4EAymg rycg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=7R2q7P1aySZbogcKB0Dxdd7G13Q9txr6d9wWetFxnQw=; b=RUw10mFX7/5kQ/SlOkDuo5wOzyXeFTkroTZ0SiBldVv5yGakOsjGA/bLbXMSBqex/l ZYHlbL42delpSldMiMGUnzjUR87YHaJmnn9DPZ9f9l97EyyodtYaB4R9bX8QXrgkBOCz ldBZVoEPIJTbNuG5sTI+rI8eKvou9jYDZP3tbrPHxOX0eYmVpVn13vhFgAyD2bO8oTkr R6Fds+0LchpYMYwQ88XCFwsumdLEXcT+7bP87uMIpN0GYvvcblAhqM1sxTC22DjN2iZ0 28C47rJUJqY8Tx/dS0naEGuEbaMqsoOf6toB0PG2K+QD003F+n7cg+OS9hftuAe4txXU eEjQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@roeck-us.net header.s=default header.b=T4oOWsW/; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x70-v6si13097874pgx.576.2018.06.01.10.35.09; Fri, 01 Jun 2018 10:35:23 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@roeck-us.net header.s=default header.b=T4oOWsW/; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752775AbeFARej (ORCPT + 99 others); Fri, 1 Jun 2018 13:34:39 -0400 Received: from bh-25.webhostbox.net ([208.91.199.152]:41943 "EHLO bh-25.webhostbox.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751502AbeFAReg (ORCPT ); Fri, 1 Jun 2018 13:34:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=roeck-us.net; s=default; h=In-Reply-To:Content-Type:MIME-Version:References :Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding :Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=7R2q7P1aySZbogcKB0Dxdd7G13Q9txr6d9wWetFxnQw=; b=T4oOWsW/5j0ky0jF9eRV+OXjJn elIaVpoauaS3Rc3ygjxTircQoh1RL67cZuFg8qcVLyQQGhvqdh7RWy1GKMnSmsBphlERwxh5A/ZLu tOafHCTvoXGNP76t2pPxWGuO3gWPMF/Qv8SbBV5iLa/q4FY/xDSYzNFJsQGI+WOqd7nyvZqVGwuhu 3de3t1dh9cR8XgTuH7F2IVgAVNB2P3641ugZ89kSB/7njTBsDqAXNtgyqeHm+foTYy9RvVniZE4cV HjMKrpnqI2J/Alfmq7VtkQhmL5qCX83sYSR2xjEYGAlJKmFxOJzTBGACX/OXc39pNQm+fz+GcSFBo ymwyxOSQ==; Received: from 108-223-40-66.lightspeed.sntcca.sbcglobal.net ([108.223.40.66]:36860 helo=localhost) by bh-25.webhostbox.net with esmtpa (Exim 4.89) (envelope-from ) id 1fOnwh-000AdM-Ep; Fri, 01 Jun 2018 17:34:36 +0000 Date: Fri, 1 Jun 2018 10:34:34 -0700 From: Guenter Roeck To: Brian Norris Cc: Sebastian Reichel , linux-kernel@vger.kernel.org, Rob Herring , linux-pm@vger.kernel.org, devicetree@vger.kernel.org, Rhyland Klein , Alexandru Stan , Doug Anderson Subject: Re: [PATCH v2 1/2] power: supply: sbs-battery: don't assume MANUFACTURER_DATA formats Message-ID: <20180601173434.GA22509@roeck-us.net> References: <20180601172400.50737-1-briannorris@chromium.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180601172400.50737-1-briannorris@chromium.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-Authenticated_sender: guenter@roeck-us.net X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - bh-25.webhostbox.net X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - roeck-us.net X-Get-Message-Sender-Via: bh-25.webhostbox.net: authenticated_id: guenter@roeck-us.net X-Authenticated-Sender: bh-25.webhostbox.net: guenter@roeck-us.net X-Source: X-Source-Args: X-Source-Dir: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 01, 2018 at 10:23:59AM -0700, Brian Norris wrote: > This driver was originally submitted for the TI BQ20Z75 battery IC > (commit a7640bfa10c5 ("power_supply: Add driver for TI BQ20Z75 gas gauge > IC")) and later renamed to express generic SBS support. While it's > mostly true that this driver implemented a standard SBS command set, it > takes liberties with the REG_MANUFACTURER_DATA register. This register > is specified in the SBS spec, but it doesn't make any mention of what > its actual contents are. > > We've sort of noticed this optionality previously, with commit > 17c6d3979e5b ("sbs-battery: make writes to ManufacturerAccess > optional"), where we found that some batteries NAK writes to this > register. > > What this really means is that so far, we've just been lucky that most > batteries have either been compatible with the TI chip, or else at least > haven't reported highly-unexpected values. > > For instance, one battery I have here seems to report either 0x0000 or > 0x0100 to the MANUFACTURER_ACCESS_STATUS command -- while this seems to > match either Wake Up (bits[11:8] = 0000b) or Normal Discharge > (bits[11:8] = 0001b) status for the TI part [1], they don't seem to > actually correspond to real states (for instance, I never see 0101b = > Charge, even when charging). > > On other batteries, I'm getting apparently random data in return, which > means that occasionally, we interpret this as "battery not present" or > "battery is not healthy". > > All in all, it seems to be a really bad idea to make assumptions about > REG_MANUFACTURER_DATA, unless we already know what battery we're using. > Therefore, this patch reimplements the "present" and "health" checks to > the following on most SBS batteries: > > 1. HEALTH: report "unknown" -- I couldn't find a standard SBS command > that gives us much useful here > 2. PRESENT: just send a REG_STATUS command; if it succeeds, then the > battery is present > > Also, we stop sending MANUFACTURER_ACCESS_SLEEP to non-TI parts. I have > no proof that this is useful and supported. > > If someone explicitly provided a 'ti,bq20z75' compatible property, then > we retain the existing TI command behaviors. > > [1] http://www.ti.com/lit/er/sluu265a/sluu265a.pdf > > Signed-off-by: Brian Norris > --- > v2: > * don't stub out POWER_SUPPLY_PROP_PRESENT from sbs_data[] > * use if/else instead of switch/case > --- > drivers/power/supply/sbs-battery.c | 54 +++++++++++++++++++++++++----- > 1 file changed, 46 insertions(+), 8 deletions(-) > > diff --git a/drivers/power/supply/sbs-battery.c b/drivers/power/supply/sbs-battery.c > index 83d7b4115857..8dea63464a3f 100644 > --- a/drivers/power/supply/sbs-battery.c > +++ b/drivers/power/supply/sbs-battery.c > @@ -23,6 +23,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -156,6 +157,9 @@ static enum power_supply_property sbs_properties[] = { > POWER_SUPPLY_PROP_MODEL_NAME > }; > > +/* Supports special manufacturer commands from TI BQ20Z75 IC. */ > +#define SBS_FLAGS_TI_BQ20Z75 BIT(0) > + > struct sbs_info { > struct i2c_client *client; > struct power_supply *power_supply; > @@ -168,6 +172,7 @@ struct sbs_info { > u32 poll_retry_count; > struct delayed_work work; > struct mutex mode_lock; > + u32 flags; > }; > > static char model_name[I2C_SMBUS_BLOCK_MAX + 1]; > @@ -315,6 +320,27 @@ static int sbs_status_correct(struct i2c_client *client, int *intval) > static int sbs_get_battery_presence_and_health( > struct i2c_client *client, enum power_supply_property psp, > union power_supply_propval *val) > +{ > + int ret; > + > + if (psp == POWER_SUPPLY_PROP_PRESENT) { > + /* Dummy command; if it succeeds, battery is present. */ > + ret = sbs_read_word_data(client, sbs_data[REG_STATUS].addr); > + if (ret < 0) > + val->intval = 0; /* battery disconnected */ > + else > + val->intval = 1; /* battery present */ > + return 0; > + } else { /* POWER_SUPPLY_PROP_HEALTH */ Static analyzers may complain that else after return is unnecessary. Other than that Reviewed-by: Guenter Roeck > + /* SBS spec doesn't have a general health command. */ > + val->intval = POWER_SUPPLY_HEALTH_UNKNOWN; > + return 0; > + } > +} > + > +static int sbs_get_ti_battery_presence_and_health( > + struct i2c_client *client, enum power_supply_property psp, > + union power_supply_propval *val) > { > s32 ret; > > @@ -600,7 +626,12 @@ static int sbs_get_property(struct power_supply *psy, > switch (psp) { > case POWER_SUPPLY_PROP_PRESENT: > case POWER_SUPPLY_PROP_HEALTH: > - ret = sbs_get_battery_presence_and_health(client, psp, val); > + if (client->flags & SBS_FLAGS_TI_BQ20Z75) > + ret = sbs_get_ti_battery_presence_and_health(client, > + psp, val); > + else > + ret = sbs_get_battery_presence_and_health(client, psp, > + val); > if (psp == POWER_SUPPLY_PROP_PRESENT) > return 0; > break; > @@ -806,6 +837,7 @@ static int sbs_probe(struct i2c_client *client, > if (!chip) > return -ENOMEM; > > + chip->flags = (u32)(uintptr_t)of_device_get_match_data(&client->dev); > chip->client = client; > chip->enable_detection = false; > psy_cfg.of_node = client->dev.of_node; > @@ -915,12 +947,15 @@ static int sbs_suspend(struct device *dev) > if (chip->poll_time > 0) > cancel_delayed_work_sync(&chip->work); > > - /* > - * Write to manufacturer access with sleep command. > - * Support is manufacturer dependend, so ignore errors. > - */ > - sbs_write_word_data(client, sbs_data[REG_MANUFACTURER_DATA].addr, > - MANUFACTURER_ACCESS_SLEEP); > + if (chip->flags & SBS_FLAGS_TI_BQ20Z75) { > + /* > + * Write to manufacturer access with sleep command. > + * Support is manufacturer dependent, so ignore errors. > + */ > + sbs_write_word_data(client, > + sbs_data[REG_MANUFACTURER_DATA].addr, > + MANUFACTURER_ACCESS_SLEEP); > + } > > return 0; > } > @@ -941,7 +976,10 @@ MODULE_DEVICE_TABLE(i2c, sbs_id); > > static const struct of_device_id sbs_dt_ids[] = { > { .compatible = "sbs,sbs-battery" }, > - { .compatible = "ti,bq20z75" }, > + { > + .compatible = "ti,bq20z75", > + .data = (void *)SBS_FLAGS_TI_BQ20Z75, > + }, > { } > }; > MODULE_DEVICE_TABLE(of, sbs_dt_ids); > -- > 2.17.0.921.gf22659ad46-goog >