2019-05-27 14:55:06 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-or-later
|
2010-09-06 06:31:23 +08:00
|
|
|
/*
|
2011-12-06 09:50:46 +08:00
|
|
|
* Gas Gauge driver for SBS Compliant Batteries
|
2010-09-06 06:31:23 +08:00
|
|
|
*
|
|
|
|
* Copyright (c) 2010, NVIDIA Corporation.
|
|
|
|
*/
|
|
|
|
|
2019-11-02 03:07:03 +08:00
|
|
|
#include <linux/bits.h>
|
2017-07-11 17:43:43 +08:00
|
|
|
#include <linux/delay.h>
|
2010-09-06 06:31:23 +08:00
|
|
|
#include <linux/err.h>
|
2017-07-11 17:43:42 +08:00
|
|
|
#include <linux/gpio/consumer.h>
|
2010-09-06 06:31:23 +08:00
|
|
|
#include <linux/i2c.h>
|
2017-07-11 17:43:42 +08:00
|
|
|
#include <linux/init.h>
|
2011-03-01 08:55:28 +08:00
|
|
|
#include <linux/interrupt.h>
|
2017-07-11 17:43:42 +08:00
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/module.h>
|
2020-05-14 02:56:12 +08:00
|
|
|
#include <linux/property.h>
|
power: supply: sbs-battery: don't assume MANUFACTURER_DATA formats
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 continue to use the existing TI command behaviors, and we effectively
revert commit 17c6d3979e5b ("sbs-battery: make writes to
ManufacturerAccess optional") to again make these commands required.
[1] http://www.ti.com/lit/er/sluu265a/sluu265a.pdf
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Rhyland Klein <rklein@nvidia.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
2018-06-13 04:20:41 +08:00
|
|
|
#include <linux/of_device.h>
|
2011-12-06 09:50:46 +08:00
|
|
|
#include <linux/power/sbs-battery.h>
|
2017-07-11 17:43:42 +08:00
|
|
|
#include <linux/power_supply.h>
|
|
|
|
#include <linux/slab.h>
|
|
|
|
#include <linux/stat.h>
|
2010-09-06 06:31:23 +08:00
|
|
|
|
|
|
|
enum {
|
|
|
|
REG_MANUFACTURER_DATA,
|
2020-05-14 02:56:09 +08:00
|
|
|
REG_BATTERY_MODE,
|
2010-09-06 06:31:23 +08:00
|
|
|
REG_TEMPERATURE,
|
|
|
|
REG_VOLTAGE,
|
2020-05-14 02:56:05 +08:00
|
|
|
REG_CURRENT_NOW,
|
|
|
|
REG_CURRENT_AVG,
|
2020-05-14 02:56:02 +08:00
|
|
|
REG_MAX_ERR,
|
2010-09-06 06:31:23 +08:00
|
|
|
REG_CAPACITY,
|
|
|
|
REG_TIME_TO_EMPTY,
|
|
|
|
REG_TIME_TO_FULL,
|
|
|
|
REG_STATUS,
|
2016-08-12 00:59:12 +08:00
|
|
|
REG_CAPACITY_LEVEL,
|
2010-09-06 06:31:23 +08:00
|
|
|
REG_CYCLE_COUNT,
|
2010-09-22 06:33:55 +08:00
|
|
|
REG_SERIAL_NUMBER,
|
|
|
|
REG_REMAINING_CAPACITY,
|
2011-01-26 03:10:06 +08:00
|
|
|
REG_REMAINING_CAPACITY_CHARGE,
|
2010-09-22 06:33:55 +08:00
|
|
|
REG_FULL_CHARGE_CAPACITY,
|
2011-01-26 03:10:06 +08:00
|
|
|
REG_FULL_CHARGE_CAPACITY_CHARGE,
|
2010-09-22 06:33:55 +08:00
|
|
|
REG_DESIGN_CAPACITY,
|
2011-01-26 03:10:06 +08:00
|
|
|
REG_DESIGN_CAPACITY_CHARGE,
|
2014-08-04 19:47:46 +08:00
|
|
|
REG_DESIGN_VOLTAGE_MIN,
|
|
|
|
REG_DESIGN_VOLTAGE_MAX,
|
2020-05-14 02:56:06 +08:00
|
|
|
REG_CHEMISTRY,
|
2014-08-04 19:47:45 +08:00
|
|
|
REG_MANUFACTURER,
|
|
|
|
REG_MODEL_NAME,
|
2020-05-14 02:56:07 +08:00
|
|
|
REG_CHARGE_CURRENT,
|
|
|
|
REG_CHARGE_VOLTAGE,
|
2010-09-06 06:31:23 +08:00
|
|
|
};
|
|
|
|
|
2020-05-14 02:56:08 +08:00
|
|
|
#define REG_ADDR_MANUFACTURE_DATE 0x1B
|
|
|
|
|
2011-01-26 03:10:06 +08:00
|
|
|
/* Battery Mode defines */
|
|
|
|
#define BATTERY_MODE_OFFSET 0x03
|
2019-11-02 03:07:03 +08:00
|
|
|
#define BATTERY_MODE_CAPACITY_MASK BIT(15)
|
|
|
|
enum sbs_capacity_mode {
|
|
|
|
CAPACITY_MODE_AMPS = 0,
|
|
|
|
CAPACITY_MODE_WATTS = BATTERY_MODE_CAPACITY_MASK
|
2011-01-26 03:10:06 +08:00
|
|
|
};
|
2020-05-14 02:56:11 +08:00
|
|
|
#define BATTERY_MODE_CHARGER_MASK (1<<14)
|
2011-01-26 03:10:06 +08:00
|
|
|
|
2010-09-06 06:31:23 +08:00
|
|
|
/* manufacturer access defines */
|
|
|
|
#define MANUFACTURER_ACCESS_STATUS 0x0006
|
|
|
|
#define MANUFACTURER_ACCESS_SLEEP 0x0011
|
|
|
|
|
|
|
|
/* battery status value bits */
|
2016-08-12 00:59:12 +08:00
|
|
|
#define BATTERY_INITIALIZED 0x80
|
2010-09-22 06:33:55 +08:00
|
|
|
#define BATTERY_DISCHARGING 0x40
|
2010-09-06 06:31:23 +08:00
|
|
|
#define BATTERY_FULL_CHARGED 0x20
|
|
|
|
#define BATTERY_FULL_DISCHARGED 0x10
|
|
|
|
|
2014-08-04 19:47:45 +08:00
|
|
|
/* min_value and max_value are only valid for numerical data */
|
2011-12-06 09:50:46 +08:00
|
|
|
#define SBS_DATA(_psp, _addr, _min_value, _max_value) { \
|
2010-09-06 06:31:23 +08:00
|
|
|
.psp = _psp, \
|
|
|
|
.addr = _addr, \
|
|
|
|
.min_value = _min_value, \
|
|
|
|
.max_value = _max_value, \
|
|
|
|
}
|
|
|
|
|
2011-12-06 09:50:46 +08:00
|
|
|
static const struct chip_data {
|
2010-09-06 06:31:23 +08:00
|
|
|
enum power_supply_property psp;
|
|
|
|
u8 addr;
|
|
|
|
int min_value;
|
|
|
|
int max_value;
|
2011-12-06 09:50:46 +08:00
|
|
|
} sbs_data[] = {
|
2010-09-06 06:31:23 +08:00
|
|
|
[REG_MANUFACTURER_DATA] =
|
2011-12-06 09:50:46 +08:00
|
|
|
SBS_DATA(POWER_SUPPLY_PROP_PRESENT, 0x00, 0, 65535),
|
2020-05-14 02:56:09 +08:00
|
|
|
[REG_BATTERY_MODE] =
|
|
|
|
SBS_DATA(-1, 0x03, 0, 65535),
|
2010-09-06 06:31:23 +08:00
|
|
|
[REG_TEMPERATURE] =
|
2011-12-06 09:50:46 +08:00
|
|
|
SBS_DATA(POWER_SUPPLY_PROP_TEMP, 0x08, 0, 65535),
|
2010-09-06 06:31:23 +08:00
|
|
|
[REG_VOLTAGE] =
|
2011-12-06 09:50:46 +08:00
|
|
|
SBS_DATA(POWER_SUPPLY_PROP_VOLTAGE_NOW, 0x09, 0, 20000),
|
2020-05-14 02:56:05 +08:00
|
|
|
[REG_CURRENT_NOW] =
|
2011-12-06 09:50:46 +08:00
|
|
|
SBS_DATA(POWER_SUPPLY_PROP_CURRENT_NOW, 0x0A, -32768, 32767),
|
2020-05-14 02:56:05 +08:00
|
|
|
[REG_CURRENT_AVG] =
|
|
|
|
SBS_DATA(POWER_SUPPLY_PROP_CURRENT_AVG, 0x0B, -32768, 32767),
|
2020-05-14 02:56:02 +08:00
|
|
|
[REG_MAX_ERR] =
|
|
|
|
SBS_DATA(POWER_SUPPLY_PROP_CAPACITY_ERROR_MARGIN, 0x0c, 0, 100),
|
2010-09-06 06:31:23 +08:00
|
|
|
[REG_CAPACITY] =
|
2012-04-25 14:59:03 +08:00
|
|
|
SBS_DATA(POWER_SUPPLY_PROP_CAPACITY, 0x0D, 0, 100),
|
2010-09-22 06:33:55 +08:00
|
|
|
[REG_REMAINING_CAPACITY] =
|
2011-12-06 09:50:46 +08:00
|
|
|
SBS_DATA(POWER_SUPPLY_PROP_ENERGY_NOW, 0x0F, 0, 65535),
|
2011-01-26 03:10:06 +08:00
|
|
|
[REG_REMAINING_CAPACITY_CHARGE] =
|
2011-12-06 09:50:46 +08:00
|
|
|
SBS_DATA(POWER_SUPPLY_PROP_CHARGE_NOW, 0x0F, 0, 65535),
|
2010-09-22 06:33:55 +08:00
|
|
|
[REG_FULL_CHARGE_CAPACITY] =
|
2011-12-06 09:50:46 +08:00
|
|
|
SBS_DATA(POWER_SUPPLY_PROP_ENERGY_FULL, 0x10, 0, 65535),
|
2011-01-26 03:10:06 +08:00
|
|
|
[REG_FULL_CHARGE_CAPACITY_CHARGE] =
|
2011-12-06 09:50:46 +08:00
|
|
|
SBS_DATA(POWER_SUPPLY_PROP_CHARGE_FULL, 0x10, 0, 65535),
|
2010-09-06 06:31:23 +08:00
|
|
|
[REG_TIME_TO_EMPTY] =
|
2011-12-06 09:50:46 +08:00
|
|
|
SBS_DATA(POWER_SUPPLY_PROP_TIME_TO_EMPTY_AVG, 0x12, 0, 65535),
|
2010-09-06 06:31:23 +08:00
|
|
|
[REG_TIME_TO_FULL] =
|
2011-12-06 09:50:46 +08:00
|
|
|
SBS_DATA(POWER_SUPPLY_PROP_TIME_TO_FULL_AVG, 0x13, 0, 65535),
|
2020-05-14 02:56:07 +08:00
|
|
|
[REG_CHARGE_CURRENT] =
|
|
|
|
SBS_DATA(POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT_MAX, 0x14, 0, 65535),
|
|
|
|
[REG_CHARGE_VOLTAGE] =
|
|
|
|
SBS_DATA(POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE_MAX, 0x15, 0, 65535),
|
2010-09-06 06:31:23 +08:00
|
|
|
[REG_STATUS] =
|
2011-12-06 09:50:46 +08:00
|
|
|
SBS_DATA(POWER_SUPPLY_PROP_STATUS, 0x16, 0, 65535),
|
2016-08-12 00:59:12 +08:00
|
|
|
[REG_CAPACITY_LEVEL] =
|
|
|
|
SBS_DATA(POWER_SUPPLY_PROP_CAPACITY_LEVEL, 0x16, 0, 65535),
|
2010-09-06 06:31:23 +08:00
|
|
|
[REG_CYCLE_COUNT] =
|
2011-12-06 09:50:46 +08:00
|
|
|
SBS_DATA(POWER_SUPPLY_PROP_CYCLE_COUNT, 0x17, 0, 65535),
|
2010-09-22 06:33:55 +08:00
|
|
|
[REG_DESIGN_CAPACITY] =
|
2011-12-06 09:50:46 +08:00
|
|
|
SBS_DATA(POWER_SUPPLY_PROP_ENERGY_FULL_DESIGN, 0x18, 0, 65535),
|
2011-01-26 03:10:06 +08:00
|
|
|
[REG_DESIGN_CAPACITY_CHARGE] =
|
2011-12-06 09:50:46 +08:00
|
|
|
SBS_DATA(POWER_SUPPLY_PROP_CHARGE_FULL_DESIGN, 0x18, 0, 65535),
|
2014-08-04 19:47:46 +08:00
|
|
|
[REG_DESIGN_VOLTAGE_MIN] =
|
|
|
|
SBS_DATA(POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN, 0x19, 0, 65535),
|
|
|
|
[REG_DESIGN_VOLTAGE_MAX] =
|
2011-12-06 09:50:46 +08:00
|
|
|
SBS_DATA(POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN, 0x19, 0, 65535),
|
2010-09-06 06:31:23 +08:00
|
|
|
[REG_SERIAL_NUMBER] =
|
2011-12-06 09:50:46 +08:00
|
|
|
SBS_DATA(POWER_SUPPLY_PROP_SERIAL_NUMBER, 0x1C, 0, 65535),
|
2014-08-04 19:47:45 +08:00
|
|
|
/* Properties of type `const char *' */
|
|
|
|
[REG_MANUFACTURER] =
|
|
|
|
SBS_DATA(POWER_SUPPLY_PROP_MANUFACTURER, 0x20, 0, 65535),
|
|
|
|
[REG_MODEL_NAME] =
|
2020-05-14 02:56:06 +08:00
|
|
|
SBS_DATA(POWER_SUPPLY_PROP_MODEL_NAME, 0x21, 0, 65535),
|
|
|
|
[REG_CHEMISTRY] =
|
|
|
|
SBS_DATA(POWER_SUPPLY_PROP_TECHNOLOGY, 0x22, 0, 65535)
|
2010-09-06 06:31:23 +08:00
|
|
|
};
|
|
|
|
|
2020-05-14 02:56:14 +08:00
|
|
|
static const enum power_supply_property sbs_properties[] = {
|
2010-09-06 06:31:23 +08:00
|
|
|
POWER_SUPPLY_PROP_STATUS,
|
2016-08-12 00:59:12 +08:00
|
|
|
POWER_SUPPLY_PROP_CAPACITY_LEVEL,
|
2010-09-06 06:31:23 +08:00
|
|
|
POWER_SUPPLY_PROP_HEALTH,
|
|
|
|
POWER_SUPPLY_PROP_PRESENT,
|
|
|
|
POWER_SUPPLY_PROP_TECHNOLOGY,
|
|
|
|
POWER_SUPPLY_PROP_CYCLE_COUNT,
|
|
|
|
POWER_SUPPLY_PROP_VOLTAGE_NOW,
|
|
|
|
POWER_SUPPLY_PROP_CURRENT_NOW,
|
2020-05-14 02:56:05 +08:00
|
|
|
POWER_SUPPLY_PROP_CURRENT_AVG,
|
2010-09-06 06:31:23 +08:00
|
|
|
POWER_SUPPLY_PROP_CAPACITY,
|
2020-05-14 02:56:02 +08:00
|
|
|
POWER_SUPPLY_PROP_CAPACITY_ERROR_MARGIN,
|
2010-09-06 06:31:23 +08:00
|
|
|
POWER_SUPPLY_PROP_TEMP,
|
|
|
|
POWER_SUPPLY_PROP_TIME_TO_EMPTY_AVG,
|
|
|
|
POWER_SUPPLY_PROP_TIME_TO_FULL_AVG,
|
|
|
|
POWER_SUPPLY_PROP_SERIAL_NUMBER,
|
2014-08-04 19:47:46 +08:00
|
|
|
POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN,
|
2010-09-22 06:33:55 +08:00
|
|
|
POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN,
|
|
|
|
POWER_SUPPLY_PROP_ENERGY_NOW,
|
|
|
|
POWER_SUPPLY_PROP_ENERGY_FULL,
|
|
|
|
POWER_SUPPLY_PROP_ENERGY_FULL_DESIGN,
|
2011-01-26 03:10:06 +08:00
|
|
|
POWER_SUPPLY_PROP_CHARGE_NOW,
|
|
|
|
POWER_SUPPLY_PROP_CHARGE_FULL,
|
|
|
|
POWER_SUPPLY_PROP_CHARGE_FULL_DESIGN,
|
2020-05-14 02:56:07 +08:00
|
|
|
POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT_MAX,
|
|
|
|
POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE_MAX,
|
2020-05-14 02:56:08 +08:00
|
|
|
POWER_SUPPLY_PROP_MANUFACTURE_YEAR,
|
|
|
|
POWER_SUPPLY_PROP_MANUFACTURE_MONTH,
|
|
|
|
POWER_SUPPLY_PROP_MANUFACTURE_DAY,
|
2014-08-04 19:47:45 +08:00
|
|
|
/* Properties of type `const char *' */
|
|
|
|
POWER_SUPPLY_PROP_MANUFACTURER,
|
|
|
|
POWER_SUPPLY_PROP_MODEL_NAME
|
2010-09-06 06:31:23 +08:00
|
|
|
};
|
|
|
|
|
2020-05-14 02:56:01 +08:00
|
|
|
/* Supports special manufacturer commands from TI BQ20Z65 and BQ20Z75 IC. */
|
|
|
|
#define SBS_FLAGS_TI_BQ20ZX5 BIT(0)
|
power: supply: sbs-battery: don't assume MANUFACTURER_DATA formats
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 continue to use the existing TI command behaviors, and we effectively
revert commit 17c6d3979e5b ("sbs-battery: make writes to
ManufacturerAccess optional") to again make these commands required.
[1] http://www.ti.com/lit/er/sluu265a/sluu265a.pdf
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Rhyland Klein <rklein@nvidia.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
2018-06-13 04:20:41 +08:00
|
|
|
|
2011-12-06 09:50:46 +08:00
|
|
|
struct sbs_info {
|
2011-03-01 08:55:28 +08:00
|
|
|
struct i2c_client *client;
|
2015-03-12 15:44:11 +08:00
|
|
|
struct power_supply *power_supply;
|
2011-03-01 08:55:28 +08:00
|
|
|
bool is_present;
|
2016-09-01 15:50:52 +08:00
|
|
|
struct gpio_desc *gpio_detect;
|
2011-03-01 08:55:28 +08:00
|
|
|
bool enable_detection;
|
2020-05-14 02:56:11 +08:00
|
|
|
bool charger_broadcasts;
|
2011-05-25 03:05:59 +08:00
|
|
|
int last_state;
|
|
|
|
int poll_time;
|
2016-09-20 09:01:12 +08:00
|
|
|
u32 i2c_retry_count;
|
|
|
|
u32 poll_retry_count;
|
2011-05-25 03:05:59 +08:00
|
|
|
struct delayed_work work;
|
2017-06-14 01:53:25 +08:00
|
|
|
struct mutex mode_lock;
|
power: supply: sbs-battery: don't assume MANUFACTURER_DATA formats
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 continue to use the existing TI command behaviors, and we effectively
revert commit 17c6d3979e5b ("sbs-battery: make writes to
ManufacturerAccess optional") to again make these commands required.
[1] http://www.ti.com/lit/er/sluu265a/sluu265a.pdf
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Rhyland Klein <rklein@nvidia.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
2018-06-13 04:20:41 +08:00
|
|
|
u32 flags;
|
2010-09-06 06:31:23 +08:00
|
|
|
};
|
|
|
|
|
2014-08-04 19:47:45 +08:00
|
|
|
static char model_name[I2C_SMBUS_BLOCK_MAX + 1];
|
|
|
|
static char manufacturer[I2C_SMBUS_BLOCK_MAX + 1];
|
2020-05-14 02:56:06 +08:00
|
|
|
static char chemistry[I2C_SMBUS_BLOCK_MAX + 1];
|
sbs-battery: add option to always register battery
Commit a22b41a31e53 ("sbs-battery: Probe should try talking to the
device") introduced a step in probing the SBS battery, that tries to
talk to the device before actually registering it, saying:
this driver doesn't actually try talking to the device at probe
time, so if it's incorrectly configured in the device tree or
platform data (or if the battery has been removed from the system),
then probe will succeed and every access will sit there and time
out. The end result is a possibly laggy system that thinks it has a
battery but can never read status, which isn't very useful.
Which is of course reasonable. However, it is also very well possible
for a device to boot up on wall-power and be connected to a battery
later on. This is a scenario that the driver supported before said patch
was applied, and even easily achieved by booting up with the battery
attached and removing it later on. sbs-battery's 'present' sysfs file
can be used to determine if the device is available or not.
So with automated device detection lacking for now, in some cases it is
possible that one wants to register a battery, even if none are attached
at the moment. To facilitate this, add a module parameter that can be
used to configure forced loading module loading time. If set, the battery
will always be registered without checking the sanity of the connection.
Signed-off-by: Frans Klaver <frans.klaver@xsens.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
2015-06-10 20:16:56 +08:00
|
|
|
static bool force_load;
|
2014-08-04 19:47:45 +08:00
|
|
|
|
2020-05-14 02:56:11 +08:00
|
|
|
static int sbs_read_word_data(struct i2c_client *client, u8 address);
|
|
|
|
static int sbs_write_word_data(struct i2c_client *client, u8 address, u16 value);
|
|
|
|
|
|
|
|
static void sbs_disable_charger_broadcasts(struct sbs_info *chip)
|
|
|
|
{
|
|
|
|
int val = sbs_read_word_data(chip->client, BATTERY_MODE_OFFSET);
|
|
|
|
if (val < 0)
|
|
|
|
goto exit;
|
|
|
|
|
|
|
|
val |= BATTERY_MODE_CHARGER_MASK;
|
|
|
|
|
|
|
|
val = sbs_write_word_data(chip->client, BATTERY_MODE_OFFSET, val);
|
|
|
|
|
|
|
|
exit:
|
|
|
|
if (val < 0)
|
|
|
|
dev_err(&chip->client->dev,
|
|
|
|
"Failed to disable charger broadcasting: %d\n", val);
|
|
|
|
else
|
|
|
|
dev_dbg(&chip->client->dev, "%s\n", __func__);
|
|
|
|
}
|
|
|
|
|
2020-05-14 02:56:04 +08:00
|
|
|
static int sbs_update_presence(struct sbs_info *chip, bool is_present)
|
|
|
|
{
|
|
|
|
if (chip->is_present == is_present)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (!is_present) {
|
|
|
|
chip->is_present = false;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2020-05-14 02:56:11 +08:00
|
|
|
if (!chip->is_present && is_present && !chip->charger_broadcasts)
|
|
|
|
sbs_disable_charger_broadcasts(chip);
|
|
|
|
|
2020-05-14 02:56:04 +08:00
|
|
|
chip->is_present = true;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2011-12-06 09:50:46 +08:00
|
|
|
static int sbs_read_word_data(struct i2c_client *client, u8 address)
|
2010-09-22 06:33:55 +08:00
|
|
|
{
|
2011-12-06 09:50:46 +08:00
|
|
|
struct sbs_info *chip = i2c_get_clientdata(client);
|
2017-10-29 06:42:10 +08:00
|
|
|
int retries = chip->i2c_retry_count;
|
2011-03-01 08:55:29 +08:00
|
|
|
s32 ret = 0;
|
|
|
|
|
|
|
|
while (retries > 0) {
|
|
|
|
ret = i2c_smbus_read_word_data(client, address);
|
|
|
|
if (ret >= 0)
|
|
|
|
break;
|
|
|
|
retries--;
|
|
|
|
}
|
2010-09-22 06:33:55 +08:00
|
|
|
|
|
|
|
if (ret < 0) {
|
bq20z75: Fix issues with present and suspend
There are a few issues found around the battery not being present. If the
battery isn't present, then a few undesirable things happen. The first was
excessive reporting of failed properties. This was fixed by instead
returning ENODATA for all properties other than PRESENT if the battery
isn't present. That way the callers can identify the difference between a
failure and the battery not being there.
The next issue was in the suspend logic. It was found that if the battery
wasn't present, then it would return a failure, preventing the system from
going into suspend. If there is no battery present, the io is expected to
fail, so in that case, we shouldn't return the failure and just
acknowledge that it was expected.
I also found that when a gpio was used, i didn't maintain the internal
is_present state properly. I added a set of that to fix that.
Lastly, the code to see io's fail and figure out that the battery isn't
present when not using a gpio had a problem. In that code, it looked for
the read to fail and if it did, then handled it. The problem is that in
function to get the property, it first writes a value and that write can
fail, causing the code to never reach the logic after the read. Fix is
to move the logic till after the write.
Signed-off-by: Rhyland Klein <rklein@nvidia.com>
Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
2011-03-10 08:18:02 +08:00
|
|
|
dev_dbg(&client->dev,
|
2010-09-22 06:33:55 +08:00
|
|
|
"%s: i2c read at address 0x%x failed\n",
|
|
|
|
__func__, address);
|
|
|
|
return ret;
|
|
|
|
}
|
2011-03-01 08:55:29 +08:00
|
|
|
|
2017-06-15 21:59:29 +08:00
|
|
|
return ret;
|
2010-09-22 06:33:55 +08:00
|
|
|
}
|
|
|
|
|
2014-08-04 19:47:45 +08:00
|
|
|
static int sbs_read_string_data(struct i2c_client *client, u8 address,
|
|
|
|
char *values)
|
|
|
|
{
|
|
|
|
struct sbs_info *chip = i2c_get_clientdata(client);
|
2020-05-14 02:56:03 +08:00
|
|
|
int retries = chip->i2c_retry_count;
|
|
|
|
s32 ret = 0;
|
2014-08-04 19:47:45 +08:00
|
|
|
|
|
|
|
if (!i2c_check_functionality(client->adapter,
|
2020-05-14 02:56:03 +08:00
|
|
|
I2C_FUNC_SMBUS_READ_BLOCK_DATA)) {
|
2014-08-04 19:47:45 +08:00
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Get the block data */
|
2020-05-14 02:56:03 +08:00
|
|
|
while (retries > 0) {
|
|
|
|
ret = i2c_smbus_read_block_data(client, address, values);
|
2014-08-04 19:47:45 +08:00
|
|
|
if (ret >= 0)
|
|
|
|
break;
|
2020-05-14 02:56:03 +08:00
|
|
|
retries--;
|
2014-08-04 19:47:45 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
if (ret < 0) {
|
2020-05-14 02:56:03 +08:00
|
|
|
dev_dbg(&client->dev, "%s: failed to read block 0x%x: %d\n",
|
|
|
|
__func__, address, ret);
|
2014-08-04 19:47:45 +08:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2020-05-14 02:56:03 +08:00
|
|
|
/* add string termination */
|
|
|
|
values[ret] = '\0';
|
2014-08-04 19:47:45 +08:00
|
|
|
|
2020-05-14 02:56:03 +08:00
|
|
|
return 0;
|
2014-08-04 19:47:45 +08:00
|
|
|
}
|
|
|
|
|
2011-12-06 09:50:46 +08:00
|
|
|
static int sbs_write_word_data(struct i2c_client *client, u8 address,
|
2010-09-22 06:33:55 +08:00
|
|
|
u16 value)
|
|
|
|
{
|
2011-12-06 09:50:46 +08:00
|
|
|
struct sbs_info *chip = i2c_get_clientdata(client);
|
2017-10-29 06:42:10 +08:00
|
|
|
int retries = chip->i2c_retry_count;
|
2011-03-01 08:55:29 +08:00
|
|
|
s32 ret = 0;
|
|
|
|
|
|
|
|
while (retries > 0) {
|
2017-06-15 21:59:29 +08:00
|
|
|
ret = i2c_smbus_write_word_data(client, address, value);
|
2011-03-01 08:55:29 +08:00
|
|
|
if (ret >= 0)
|
|
|
|
break;
|
|
|
|
retries--;
|
|
|
|
}
|
2010-09-22 06:33:55 +08:00
|
|
|
|
|
|
|
if (ret < 0) {
|
bq20z75: Fix issues with present and suspend
There are a few issues found around the battery not being present. If the
battery isn't present, then a few undesirable things happen. The first was
excessive reporting of failed properties. This was fixed by instead
returning ENODATA for all properties other than PRESENT if the battery
isn't present. That way the callers can identify the difference between a
failure and the battery not being there.
The next issue was in the suspend logic. It was found that if the battery
wasn't present, then it would return a failure, preventing the system from
going into suspend. If there is no battery present, the io is expected to
fail, so in that case, we shouldn't return the failure and just
acknowledge that it was expected.
I also found that when a gpio was used, i didn't maintain the internal
is_present state properly. I added a set of that to fix that.
Lastly, the code to see io's fail and figure out that the battery isn't
present when not using a gpio had a problem. In that code, it looked for
the read to fail and if it did, then handled it. The problem is that in
function to get the property, it first writes a value and that write can
fail, causing the code to never reach the logic after the read. Fix is
to move the logic till after the write.
Signed-off-by: Rhyland Klein <rklein@nvidia.com>
Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
2011-03-10 08:18:02 +08:00
|
|
|
dev_dbg(&client->dev,
|
2010-09-22 06:33:55 +08:00
|
|
|
"%s: i2c write to address 0x%x failed\n",
|
|
|
|
__func__, address);
|
|
|
|
return ret;
|
|
|
|
}
|
2011-03-01 08:55:29 +08:00
|
|
|
|
2010-09-22 06:33:55 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2017-04-25 23:09:05 +08:00
|
|
|
static int sbs_status_correct(struct i2c_client *client, int *intval)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
2020-05-14 02:56:05 +08:00
|
|
|
ret = sbs_read_word_data(client, sbs_data[REG_CURRENT_NOW].addr);
|
2017-04-25 23:09:05 +08:00
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
ret = (s16)ret;
|
|
|
|
|
2020-05-14 02:56:10 +08:00
|
|
|
/* Not drawing current -> not charging (i.e. idle) */
|
|
|
|
if (*intval != POWER_SUPPLY_STATUS_FULL && ret == 0)
|
|
|
|
*intval = POWER_SUPPLY_STATUS_NOT_CHARGING;
|
2017-04-25 23:09:05 +08:00
|
|
|
|
|
|
|
if (*intval == POWER_SUPPLY_STATUS_FULL) {
|
|
|
|
/* Drawing or providing current when full */
|
|
|
|
if (ret > 0)
|
|
|
|
*intval = POWER_SUPPLY_STATUS_CHARGING;
|
|
|
|
else if (ret < 0)
|
|
|
|
*intval = POWER_SUPPLY_STATUS_DISCHARGING;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2020-05-14 02:56:09 +08:00
|
|
|
static bool sbs_bat_needs_calibration(struct i2c_client *client)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
ret = sbs_read_word_data(client, sbs_data[REG_BATTERY_MODE].addr);
|
|
|
|
if (ret < 0)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
return !!(ret & BIT(7));
|
|
|
|
}
|
|
|
|
|
2011-12-06 09:50:46 +08:00
|
|
|
static int sbs_get_battery_presence_and_health(
|
2010-09-06 06:31:23 +08:00
|
|
|
struct i2c_client *client, enum power_supply_property psp,
|
|
|
|
union power_supply_propval *val)
|
power: supply: sbs-battery: don't assume MANUFACTURER_DATA formats
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 continue to use the existing TI command behaviors, and we effectively
revert commit 17c6d3979e5b ("sbs-battery: make writes to
ManufacturerAccess optional") to again make these commands required.
[1] http://www.ti.com/lit/er/sluu265a/sluu265a.pdf
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Rhyland Klein <rklein@nvidia.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
2018-06-13 04:20:41 +08:00
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
2019-08-16 15:58:42 +08:00
|
|
|
/* Dummy command; if it succeeds, battery is present. */
|
|
|
|
ret = sbs_read_word_data(client, sbs_data[REG_STATUS].addr);
|
|
|
|
|
|
|
|
if (ret < 0) { /* battery not present*/
|
|
|
|
if (psp == POWER_SUPPLY_PROP_PRESENT) {
|
|
|
|
val->intval = 0;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (psp == POWER_SUPPLY_PROP_PRESENT)
|
|
|
|
val->intval = 1; /* battery present */
|
2020-05-14 02:56:09 +08:00
|
|
|
else { /* POWER_SUPPLY_PROP_HEALTH */
|
|
|
|
if (sbs_bat_needs_calibration(client)) {
|
|
|
|
val->intval = POWER_SUPPLY_HEALTH_CALIBRATION_REQUIRED;
|
|
|
|
} else {
|
|
|
|
/* SBS spec doesn't have a general health command. */
|
|
|
|
val->intval = POWER_SUPPLY_HEALTH_UNKNOWN;
|
|
|
|
}
|
|
|
|
}
|
power: supply: sbs-battery: don't assume MANUFACTURER_DATA formats
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 continue to use the existing TI command behaviors, and we effectively
revert commit 17c6d3979e5b ("sbs-battery: make writes to
ManufacturerAccess optional") to again make these commands required.
[1] http://www.ti.com/lit/er/sluu265a/sluu265a.pdf
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Rhyland Klein <rklein@nvidia.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
2018-06-13 04:20:41 +08:00
|
|
|
|
|
|
|
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)
|
2010-09-06 06:31:23 +08:00
|
|
|
{
|
|
|
|
s32 ret;
|
|
|
|
|
2016-09-09 10:10:00 +08:00
|
|
|
/*
|
|
|
|
* Write to ManufacturerAccess with ManufacturerAccess command
|
power: supply: sbs-battery: don't assume MANUFACTURER_DATA formats
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 continue to use the existing TI command behaviors, and we effectively
revert commit 17c6d3979e5b ("sbs-battery: make writes to
ManufacturerAccess optional") to again make these commands required.
[1] http://www.ti.com/lit/er/sluu265a/sluu265a.pdf
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Rhyland Klein <rklein@nvidia.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
2018-06-13 04:20:41 +08:00
|
|
|
* and then read the status.
|
2016-09-09 10:10:00 +08:00
|
|
|
*/
|
power: supply: sbs-battery: don't assume MANUFACTURER_DATA formats
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 continue to use the existing TI command behaviors, and we effectively
revert commit 17c6d3979e5b ("sbs-battery: make writes to
ManufacturerAccess optional") to again make these commands required.
[1] http://www.ti.com/lit/er/sluu265a/sluu265a.pdf
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Rhyland Klein <rklein@nvidia.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
2018-06-13 04:20:41 +08:00
|
|
|
ret = sbs_write_word_data(client, sbs_data[REG_MANUFACTURER_DATA].addr,
|
|
|
|
MANUFACTURER_ACCESS_STATUS);
|
|
|
|
if (ret < 0) {
|
|
|
|
if (psp == POWER_SUPPLY_PROP_PRESENT)
|
|
|
|
val->intval = 0; /* battery removed */
|
|
|
|
return ret;
|
|
|
|
}
|
2016-09-09 10:10:00 +08:00
|
|
|
|
|
|
|
ret = sbs_read_word_data(client, sbs_data[REG_MANUFACTURER_DATA].addr);
|
2011-03-01 08:55:28 +08:00
|
|
|
if (ret < 0) {
|
|
|
|
if (psp == POWER_SUPPLY_PROP_PRESENT)
|
|
|
|
val->intval = 0; /* battery removed */
|
2010-09-22 06:33:55 +08:00
|
|
|
return ret;
|
2011-03-01 08:55:28 +08:00
|
|
|
}
|
2010-09-06 06:31:23 +08:00
|
|
|
|
2011-12-06 09:50:46 +08:00
|
|
|
if (ret < sbs_data[REG_MANUFACTURER_DATA].min_value ||
|
|
|
|
ret > sbs_data[REG_MANUFACTURER_DATA].max_value) {
|
2010-09-06 06:31:23 +08:00
|
|
|
val->intval = 0;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Mask the upper nibble of 2nd byte and
|
|
|
|
* lower byte of response then
|
|
|
|
* shift the result by 8 to get status*/
|
|
|
|
ret &= 0x0F00;
|
|
|
|
ret >>= 8;
|
|
|
|
if (psp == POWER_SUPPLY_PROP_PRESENT) {
|
|
|
|
if (ret == 0x0F)
|
|
|
|
/* battery removed */
|
|
|
|
val->intval = 0;
|
|
|
|
else
|
|
|
|
val->intval = 1;
|
|
|
|
} else if (psp == POWER_SUPPLY_PROP_HEALTH) {
|
|
|
|
if (ret == 0x09)
|
|
|
|
val->intval = POWER_SUPPLY_HEALTH_UNSPEC_FAILURE;
|
|
|
|
else if (ret == 0x0B)
|
|
|
|
val->intval = POWER_SUPPLY_HEALTH_OVERHEAT;
|
|
|
|
else if (ret == 0x0C)
|
|
|
|
val->intval = POWER_SUPPLY_HEALTH_DEAD;
|
2020-05-14 02:56:09 +08:00
|
|
|
else if (sbs_bat_needs_calibration(client))
|
|
|
|
val->intval = POWER_SUPPLY_HEALTH_CALIBRATION_REQUIRED;
|
2010-09-06 06:31:23 +08:00
|
|
|
else
|
|
|
|
val->intval = POWER_SUPPLY_HEALTH_GOOD;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2011-12-06 09:50:46 +08:00
|
|
|
static int sbs_get_battery_property(struct i2c_client *client,
|
2010-09-06 06:31:23 +08:00
|
|
|
int reg_offset, enum power_supply_property psp,
|
|
|
|
union power_supply_propval *val)
|
|
|
|
{
|
2011-12-06 09:50:46 +08:00
|
|
|
struct sbs_info *chip = i2c_get_clientdata(client);
|
2010-09-06 06:31:23 +08:00
|
|
|
s32 ret;
|
|
|
|
|
2011-12-06 09:50:46 +08:00
|
|
|
ret = sbs_read_word_data(client, sbs_data[reg_offset].addr);
|
2010-09-22 06:33:55 +08:00
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
/* returned values are 16 bit */
|
2011-12-06 09:50:46 +08:00
|
|
|
if (sbs_data[reg_offset].min_value < 0)
|
2010-09-22 06:33:55 +08:00
|
|
|
ret = (s16)ret;
|
2010-09-06 06:31:23 +08:00
|
|
|
|
2011-12-06 09:50:46 +08:00
|
|
|
if (ret >= sbs_data[reg_offset].min_value &&
|
|
|
|
ret <= sbs_data[reg_offset].max_value) {
|
2010-09-06 06:31:23 +08:00
|
|
|
val->intval = ret;
|
2016-08-12 00:59:12 +08:00
|
|
|
if (psp == POWER_SUPPLY_PROP_CAPACITY_LEVEL) {
|
|
|
|
if (!(ret & BATTERY_INITIALIZED))
|
|
|
|
val->intval =
|
|
|
|
POWER_SUPPLY_CAPACITY_LEVEL_UNKNOWN;
|
|
|
|
else if (ret & BATTERY_FULL_CHARGED)
|
|
|
|
val->intval =
|
|
|
|
POWER_SUPPLY_CAPACITY_LEVEL_FULL;
|
|
|
|
else if (ret & BATTERY_FULL_DISCHARGED)
|
|
|
|
val->intval =
|
|
|
|
POWER_SUPPLY_CAPACITY_LEVEL_CRITICAL;
|
|
|
|
else
|
|
|
|
val->intval =
|
|
|
|
POWER_SUPPLY_CAPACITY_LEVEL_NORMAL;
|
2011-05-25 03:05:59 +08:00
|
|
|
return 0;
|
2016-08-12 00:59:12 +08:00
|
|
|
} else if (psp != POWER_SUPPLY_PROP_STATUS) {
|
|
|
|
return 0;
|
|
|
|
}
|
2011-05-25 03:05:59 +08:00
|
|
|
|
|
|
|
if (ret & BATTERY_FULL_CHARGED)
|
|
|
|
val->intval = POWER_SUPPLY_STATUS_FULL;
|
|
|
|
else if (ret & BATTERY_DISCHARGING)
|
|
|
|
val->intval = POWER_SUPPLY_STATUS_DISCHARGING;
|
|
|
|
else
|
|
|
|
val->intval = POWER_SUPPLY_STATUS_CHARGING;
|
|
|
|
|
2017-04-25 23:09:05 +08:00
|
|
|
sbs_status_correct(client, &val->intval);
|
|
|
|
|
2011-12-06 09:50:46 +08:00
|
|
|
if (chip->poll_time == 0)
|
|
|
|
chip->last_state = val->intval;
|
|
|
|
else if (chip->last_state != val->intval) {
|
|
|
|
cancel_delayed_work_sync(&chip->work);
|
2015-03-12 15:44:11 +08:00
|
|
|
power_supply_changed(chip->power_supply);
|
2011-12-06 09:50:46 +08:00
|
|
|
chip->poll_time = 0;
|
2010-09-06 06:31:23 +08:00
|
|
|
}
|
|
|
|
} else {
|
|
|
|
if (psp == POWER_SUPPLY_PROP_STATUS)
|
|
|
|
val->intval = POWER_SUPPLY_STATUS_UNKNOWN;
|
2017-06-14 01:53:26 +08:00
|
|
|
else if (psp == POWER_SUPPLY_PROP_CAPACITY)
|
|
|
|
/* sbs spec says that this can be >100 %
|
|
|
|
* even if max value is 100 %
|
|
|
|
*/
|
|
|
|
val->intval = min(ret, 100);
|
2010-09-06 06:31:23 +08:00
|
|
|
else
|
|
|
|
val->intval = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2014-08-04 19:47:45 +08:00
|
|
|
static int sbs_get_battery_string_property(struct i2c_client *client,
|
|
|
|
int reg_offset, enum power_supply_property psp, char *val)
|
|
|
|
{
|
2020-05-14 02:56:03 +08:00
|
|
|
return sbs_read_string_data(client, sbs_data[reg_offset].addr, val);
|
2014-08-04 19:47:45 +08:00
|
|
|
}
|
|
|
|
|
2011-12-06 09:50:46 +08:00
|
|
|
static void sbs_unit_adjustment(struct i2c_client *client,
|
2010-09-22 06:33:55 +08:00
|
|
|
enum power_supply_property psp, union power_supply_propval *val)
|
|
|
|
{
|
|
|
|
#define BASE_UNIT_CONVERSION 1000
|
|
|
|
#define BATTERY_MODE_CAP_MULT_WATT (10 * BASE_UNIT_CONVERSION)
|
2011-02-28 09:41:48 +08:00
|
|
|
#define TIME_UNIT_CONVERSION 60
|
|
|
|
#define TEMP_KELVIN_TO_CELSIUS 2731
|
2010-09-22 06:33:55 +08:00
|
|
|
switch (psp) {
|
|
|
|
case POWER_SUPPLY_PROP_ENERGY_NOW:
|
|
|
|
case POWER_SUPPLY_PROP_ENERGY_FULL:
|
|
|
|
case POWER_SUPPLY_PROP_ENERGY_FULL_DESIGN:
|
2011-12-06 09:50:46 +08:00
|
|
|
/* sbs provides energy in units of 10mWh.
|
2011-02-28 09:41:48 +08:00
|
|
|
* Convert to µWh
|
|
|
|
*/
|
2010-09-22 06:33:55 +08:00
|
|
|
val->intval *= BATTERY_MODE_CAP_MULT_WATT;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case POWER_SUPPLY_PROP_VOLTAGE_NOW:
|
2014-08-04 19:47:46 +08:00
|
|
|
case POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN:
|
2010-09-22 06:33:55 +08:00
|
|
|
case POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN:
|
|
|
|
case POWER_SUPPLY_PROP_CURRENT_NOW:
|
2020-05-14 02:56:05 +08:00
|
|
|
case POWER_SUPPLY_PROP_CURRENT_AVG:
|
2011-01-26 03:10:06 +08:00
|
|
|
case POWER_SUPPLY_PROP_CHARGE_NOW:
|
2020-05-14 02:56:07 +08:00
|
|
|
case POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT_MAX:
|
|
|
|
case POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE_MAX:
|
2011-01-26 03:10:06 +08:00
|
|
|
case POWER_SUPPLY_PROP_CHARGE_FULL:
|
|
|
|
case POWER_SUPPLY_PROP_CHARGE_FULL_DESIGN:
|
2010-09-22 06:33:55 +08:00
|
|
|
val->intval *= BASE_UNIT_CONVERSION;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case POWER_SUPPLY_PROP_TEMP:
|
2011-12-06 09:50:46 +08:00
|
|
|
/* sbs provides battery temperature in 0.1K
|
2011-02-28 09:41:48 +08:00
|
|
|
* so convert it to 0.1°C
|
|
|
|
*/
|
|
|
|
val->intval -= TEMP_KELVIN_TO_CELSIUS;
|
2010-09-22 06:33:55 +08:00
|
|
|
break;
|
|
|
|
|
|
|
|
case POWER_SUPPLY_PROP_TIME_TO_EMPTY_AVG:
|
|
|
|
case POWER_SUPPLY_PROP_TIME_TO_FULL_AVG:
|
2011-12-06 09:50:46 +08:00
|
|
|
/* sbs provides time to empty and time to full in minutes.
|
2011-02-28 09:41:48 +08:00
|
|
|
* Convert to seconds
|
|
|
|
*/
|
2010-09-22 06:33:55 +08:00
|
|
|
val->intval *= TIME_UNIT_CONVERSION;
|
|
|
|
break;
|
|
|
|
|
|
|
|
default:
|
|
|
|
dev_dbg(&client->dev,
|
|
|
|
"%s: no need for unit conversion %d\n", __func__, psp);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-11-02 03:07:03 +08:00
|
|
|
static enum sbs_capacity_mode sbs_set_capacity_mode(struct i2c_client *client,
|
|
|
|
enum sbs_capacity_mode mode)
|
2011-01-26 03:10:06 +08:00
|
|
|
{
|
|
|
|
int ret, original_val;
|
|
|
|
|
2011-12-06 09:50:46 +08:00
|
|
|
original_val = sbs_read_word_data(client, BATTERY_MODE_OFFSET);
|
2011-01-26 03:10:06 +08:00
|
|
|
if (original_val < 0)
|
|
|
|
return original_val;
|
|
|
|
|
2019-11-02 03:07:03 +08:00
|
|
|
if ((original_val & BATTERY_MODE_CAPACITY_MASK) == mode)
|
2011-01-26 03:10:06 +08:00
|
|
|
return mode;
|
|
|
|
|
2019-11-02 03:07:03 +08:00
|
|
|
if (mode == CAPACITY_MODE_AMPS)
|
|
|
|
ret = original_val & ~BATTERY_MODE_CAPACITY_MASK;
|
2011-01-26 03:10:06 +08:00
|
|
|
else
|
2019-11-02 03:07:03 +08:00
|
|
|
ret = original_val | BATTERY_MODE_CAPACITY_MASK;
|
2011-01-26 03:10:06 +08:00
|
|
|
|
2011-12-06 09:50:46 +08:00
|
|
|
ret = sbs_write_word_data(client, BATTERY_MODE_OFFSET, ret);
|
2011-01-26 03:10:06 +08:00
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
|
2017-07-11 17:43:43 +08:00
|
|
|
usleep_range(1000, 2000);
|
|
|
|
|
2019-11-02 03:07:03 +08:00
|
|
|
return original_val & BATTERY_MODE_CAPACITY_MASK;
|
2011-01-26 03:10:06 +08:00
|
|
|
}
|
|
|
|
|
2011-12-06 09:50:46 +08:00
|
|
|
static int sbs_get_battery_capacity(struct i2c_client *client,
|
2010-09-22 06:33:55 +08:00
|
|
|
int reg_offset, enum power_supply_property psp,
|
2010-09-06 06:31:23 +08:00
|
|
|
union power_supply_propval *val)
|
|
|
|
{
|
|
|
|
s32 ret;
|
2019-11-02 03:07:03 +08:00
|
|
|
enum sbs_capacity_mode mode = CAPACITY_MODE_WATTS;
|
2011-01-26 03:10:06 +08:00
|
|
|
|
|
|
|
if (power_supply_is_amp_property(psp))
|
2019-11-02 03:07:03 +08:00
|
|
|
mode = CAPACITY_MODE_AMPS;
|
2011-01-26 03:10:06 +08:00
|
|
|
|
2019-11-02 03:07:03 +08:00
|
|
|
mode = sbs_set_capacity_mode(client, mode);
|
2019-09-25 19:01:28 +08:00
|
|
|
if ((int)mode < 0)
|
2011-01-26 03:10:06 +08:00
|
|
|
return mode;
|
2010-09-06 06:31:23 +08:00
|
|
|
|
2011-12-06 09:50:46 +08:00
|
|
|
ret = sbs_read_word_data(client, sbs_data[reg_offset].addr);
|
2010-09-22 06:33:55 +08:00
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
2010-09-06 06:31:23 +08:00
|
|
|
|
2017-06-14 01:53:26 +08:00
|
|
|
val->intval = ret;
|
2010-09-22 06:33:55 +08:00
|
|
|
|
2019-11-02 03:07:03 +08:00
|
|
|
ret = sbs_set_capacity_mode(client, mode);
|
2011-01-26 03:10:06 +08:00
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
|
2010-09-22 06:33:55 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2011-12-06 09:50:46 +08:00
|
|
|
static char sbs_serial[5];
|
|
|
|
static int sbs_get_battery_serial_number(struct i2c_client *client,
|
2010-09-22 06:33:55 +08:00
|
|
|
union power_supply_propval *val)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
2011-12-06 09:50:46 +08:00
|
|
|
ret = sbs_read_word_data(client, sbs_data[REG_SERIAL_NUMBER].addr);
|
2010-09-22 06:33:55 +08:00
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
|
2017-10-29 06:45:59 +08:00
|
|
|
sprintf(sbs_serial, "%04x", ret);
|
2011-12-06 09:50:46 +08:00
|
|
|
val->strval = sbs_serial;
|
2010-09-06 06:31:23 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2011-12-06 09:50:46 +08:00
|
|
|
static int sbs_get_property_index(struct i2c_client *client,
|
2011-01-26 03:10:06 +08:00
|
|
|
enum power_supply_property psp)
|
|
|
|
{
|
|
|
|
int count;
|
2011-12-06 09:50:46 +08:00
|
|
|
for (count = 0; count < ARRAY_SIZE(sbs_data); count++)
|
|
|
|
if (psp == sbs_data[count].psp)
|
2011-01-26 03:10:06 +08:00
|
|
|
return count;
|
|
|
|
|
|
|
|
dev_warn(&client->dev,
|
|
|
|
"%s: Invalid Property - %d\n", __func__, psp);
|
|
|
|
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2020-05-14 02:56:06 +08:00
|
|
|
static int sbs_get_chemistry(struct i2c_client *client,
|
|
|
|
union power_supply_propval *val)
|
|
|
|
{
|
|
|
|
enum power_supply_property psp = POWER_SUPPLY_PROP_TECHNOLOGY;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
ret = sbs_get_property_index(client, psp);
|
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
ret = sbs_get_battery_string_property(client, ret, psp,
|
|
|
|
chemistry);
|
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
if (!strncasecmp(chemistry, "LION", 4))
|
|
|
|
val->intval = POWER_SUPPLY_TECHNOLOGY_LION;
|
|
|
|
else if (!strncasecmp(chemistry, "LiP", 3))
|
|
|
|
val->intval = POWER_SUPPLY_TECHNOLOGY_LIPO;
|
|
|
|
else if (!strncasecmp(chemistry, "NiCd", 4))
|
|
|
|
val->intval = POWER_SUPPLY_TECHNOLOGY_NiCd;
|
|
|
|
else if (!strncasecmp(chemistry, "NiMH", 4))
|
|
|
|
val->intval = POWER_SUPPLY_TECHNOLOGY_NiMH;
|
|
|
|
else
|
|
|
|
val->intval = POWER_SUPPLY_TECHNOLOGY_UNKNOWN;
|
|
|
|
|
|
|
|
if (val->intval == POWER_SUPPLY_TECHNOLOGY_UNKNOWN)
|
|
|
|
dev_warn(&client->dev, "Unknown chemistry: %s\n", chemistry);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2020-05-14 02:56:08 +08:00
|
|
|
static int sbs_get_battery_manufacture_date(struct i2c_client *client,
|
|
|
|
enum power_supply_property psp,
|
|
|
|
union power_supply_propval *val)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
u16 day, month, year;
|
|
|
|
|
|
|
|
ret = sbs_read_word_data(client, REG_ADDR_MANUFACTURE_DATE);
|
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
day = ret & GENMASK(4, 0);
|
|
|
|
month = (ret & GENMASK(8, 5)) >> 5;
|
|
|
|
year = ((ret & GENMASK(15, 9)) >> 9) + 1980;
|
|
|
|
|
|
|
|
switch (psp) {
|
|
|
|
case POWER_SUPPLY_PROP_MANUFACTURE_YEAR:
|
|
|
|
val->intval = year;
|
|
|
|
break;
|
|
|
|
case POWER_SUPPLY_PROP_MANUFACTURE_MONTH:
|
|
|
|
val->intval = month;
|
|
|
|
break;
|
|
|
|
case POWER_SUPPLY_PROP_MANUFACTURE_DAY:
|
|
|
|
val->intval = day;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2011-12-06 09:50:46 +08:00
|
|
|
static int sbs_get_property(struct power_supply *psy,
|
2010-09-06 06:31:23 +08:00
|
|
|
enum power_supply_property psp,
|
|
|
|
union power_supply_propval *val)
|
|
|
|
{
|
2011-03-01 08:55:28 +08:00
|
|
|
int ret = 0;
|
2015-03-12 15:44:11 +08:00
|
|
|
struct sbs_info *chip = power_supply_get_drvdata(psy);
|
2011-12-06 09:50:46 +08:00
|
|
|
struct i2c_client *client = chip->client;
|
2010-09-06 06:31:23 +08:00
|
|
|
|
2017-08-24 17:31:10 +08:00
|
|
|
if (chip->gpio_detect) {
|
|
|
|
ret = gpiod_get_value_cansleep(chip->gpio_detect);
|
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
if (psp == POWER_SUPPLY_PROP_PRESENT) {
|
|
|
|
val->intval = ret;
|
2020-05-14 02:56:04 +08:00
|
|
|
sbs_update_presence(chip, ret);
|
2017-08-24 17:31:10 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
if (ret == 0)
|
|
|
|
return -ENODATA;
|
|
|
|
}
|
|
|
|
|
2010-09-06 06:31:23 +08:00
|
|
|
switch (psp) {
|
|
|
|
case POWER_SUPPLY_PROP_PRESENT:
|
|
|
|
case POWER_SUPPLY_PROP_HEALTH:
|
2020-05-14 02:56:01 +08:00
|
|
|
if (chip->flags & SBS_FLAGS_TI_BQ20ZX5)
|
power: supply: sbs-battery: don't assume MANUFACTURER_DATA formats
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 continue to use the existing TI command behaviors, and we effectively
revert commit 17c6d3979e5b ("sbs-battery: make writes to
ManufacturerAccess optional") to again make these commands required.
[1] http://www.ti.com/lit/er/sluu265a/sluu265a.pdf
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Rhyland Klein <rklein@nvidia.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
2018-06-13 04:20:41 +08:00
|
|
|
ret = sbs_get_ti_battery_presence_and_health(client,
|
|
|
|
psp, val);
|
|
|
|
else
|
|
|
|
ret = sbs_get_battery_presence_and_health(client, psp,
|
|
|
|
val);
|
2019-08-16 15:58:42 +08:00
|
|
|
|
|
|
|
/* this can only be true if no gpio is used */
|
bq20z75: Fix issues with present and suspend
There are a few issues found around the battery not being present. If the
battery isn't present, then a few undesirable things happen. The first was
excessive reporting of failed properties. This was fixed by instead
returning ENODATA for all properties other than PRESENT if the battery
isn't present. That way the callers can identify the difference between a
failure and the battery not being there.
The next issue was in the suspend logic. It was found that if the battery
wasn't present, then it would return a failure, preventing the system from
going into suspend. If there is no battery present, the io is expected to
fail, so in that case, we shouldn't return the failure and just
acknowledge that it was expected.
I also found that when a gpio was used, i didn't maintain the internal
is_present state properly. I added a set of that to fix that.
Lastly, the code to see io's fail and figure out that the battery isn't
present when not using a gpio had a problem. In that code, it looked for
the read to fail and if it did, then handled it. The problem is that in
function to get the property, it first writes a value and that write can
fail, causing the code to never reach the logic after the read. Fix is
to move the logic till after the write.
Signed-off-by: Rhyland Klein <rklein@nvidia.com>
Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
2011-03-10 08:18:02 +08:00
|
|
|
if (psp == POWER_SUPPLY_PROP_PRESENT)
|
|
|
|
return 0;
|
2010-09-06 06:31:23 +08:00
|
|
|
break;
|
|
|
|
|
|
|
|
case POWER_SUPPLY_PROP_TECHNOLOGY:
|
2020-05-14 02:56:06 +08:00
|
|
|
ret = sbs_get_chemistry(client, val);
|
|
|
|
if (ret < 0)
|
|
|
|
break;
|
|
|
|
|
2012-05-09 14:30:44 +08:00
|
|
|
goto done; /* don't trigger power_supply_changed()! */
|
2010-09-06 06:31:23 +08:00
|
|
|
|
2010-09-22 06:33:55 +08:00
|
|
|
case POWER_SUPPLY_PROP_ENERGY_NOW:
|
|
|
|
case POWER_SUPPLY_PROP_ENERGY_FULL:
|
|
|
|
case POWER_SUPPLY_PROP_ENERGY_FULL_DESIGN:
|
2011-01-26 03:10:06 +08:00
|
|
|
case POWER_SUPPLY_PROP_CHARGE_NOW:
|
|
|
|
case POWER_SUPPLY_PROP_CHARGE_FULL:
|
|
|
|
case POWER_SUPPLY_PROP_CHARGE_FULL_DESIGN:
|
2011-12-06 09:50:46 +08:00
|
|
|
ret = sbs_get_property_index(client, psp);
|
2011-03-01 08:55:28 +08:00
|
|
|
if (ret < 0)
|
|
|
|
break;
|
2010-09-22 06:33:55 +08:00
|
|
|
|
2017-06-14 01:53:25 +08:00
|
|
|
/* sbs_get_battery_capacity() will change the battery mode
|
|
|
|
* temporarily to read the requested attribute. Ensure we stay
|
|
|
|
* in the desired mode for the duration of the attribute read.
|
|
|
|
*/
|
|
|
|
mutex_lock(&chip->mode_lock);
|
2011-12-06 09:50:46 +08:00
|
|
|
ret = sbs_get_battery_capacity(client, ret, psp, val);
|
2017-06-14 01:53:25 +08:00
|
|
|
mutex_unlock(&chip->mode_lock);
|
2010-09-22 06:33:55 +08:00
|
|
|
break;
|
|
|
|
|
|
|
|
case POWER_SUPPLY_PROP_SERIAL_NUMBER:
|
2011-12-06 09:50:46 +08:00
|
|
|
ret = sbs_get_battery_serial_number(client, val);
|
2010-09-06 06:31:23 +08:00
|
|
|
break;
|
|
|
|
|
|
|
|
case POWER_SUPPLY_PROP_STATUS:
|
2016-08-12 00:59:12 +08:00
|
|
|
case POWER_SUPPLY_PROP_CAPACITY_LEVEL:
|
2010-09-06 06:31:23 +08:00
|
|
|
case POWER_SUPPLY_PROP_CYCLE_COUNT:
|
|
|
|
case POWER_SUPPLY_PROP_VOLTAGE_NOW:
|
|
|
|
case POWER_SUPPLY_PROP_CURRENT_NOW:
|
2020-05-14 02:56:05 +08:00
|
|
|
case POWER_SUPPLY_PROP_CURRENT_AVG:
|
2010-09-06 06:31:23 +08:00
|
|
|
case POWER_SUPPLY_PROP_TEMP:
|
|
|
|
case POWER_SUPPLY_PROP_TIME_TO_EMPTY_AVG:
|
|
|
|
case POWER_SUPPLY_PROP_TIME_TO_FULL_AVG:
|
2014-08-04 19:47:46 +08:00
|
|
|
case POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN:
|
2010-09-22 06:33:55 +08:00
|
|
|
case POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN:
|
2020-05-14 02:56:07 +08:00
|
|
|
case POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT_MAX:
|
|
|
|
case POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE_MAX:
|
2017-06-14 01:53:26 +08:00
|
|
|
case POWER_SUPPLY_PROP_CAPACITY:
|
2020-05-14 02:56:02 +08:00
|
|
|
case POWER_SUPPLY_PROP_CAPACITY_ERROR_MARGIN:
|
2011-12-06 09:50:46 +08:00
|
|
|
ret = sbs_get_property_index(client, psp);
|
2011-03-01 08:55:28 +08:00
|
|
|
if (ret < 0)
|
|
|
|
break;
|
2010-09-22 06:33:55 +08:00
|
|
|
|
2011-12-06 09:50:46 +08:00
|
|
|
ret = sbs_get_battery_property(client, ret, psp, val);
|
2010-09-06 06:31:23 +08:00
|
|
|
break;
|
|
|
|
|
2014-08-04 19:47:45 +08:00
|
|
|
case POWER_SUPPLY_PROP_MODEL_NAME:
|
|
|
|
ret = sbs_get_property_index(client, psp);
|
|
|
|
if (ret < 0)
|
|
|
|
break;
|
|
|
|
|
|
|
|
ret = sbs_get_battery_string_property(client, ret, psp,
|
|
|
|
model_name);
|
|
|
|
val->strval = model_name;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case POWER_SUPPLY_PROP_MANUFACTURER:
|
|
|
|
ret = sbs_get_property_index(client, psp);
|
|
|
|
if (ret < 0)
|
|
|
|
break;
|
|
|
|
|
|
|
|
ret = sbs_get_battery_string_property(client, ret, psp,
|
|
|
|
manufacturer);
|
|
|
|
val->strval = manufacturer;
|
|
|
|
break;
|
|
|
|
|
2020-05-14 02:56:08 +08:00
|
|
|
case POWER_SUPPLY_PROP_MANUFACTURE_YEAR:
|
|
|
|
case POWER_SUPPLY_PROP_MANUFACTURE_MONTH:
|
|
|
|
case POWER_SUPPLY_PROP_MANUFACTURE_DAY:
|
|
|
|
ret = sbs_get_battery_manufacture_date(client, psp, val);
|
|
|
|
break;
|
|
|
|
|
2010-09-06 06:31:23 +08:00
|
|
|
default:
|
|
|
|
dev_err(&client->dev,
|
|
|
|
"%s: INVALID property\n", __func__);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2011-12-06 09:50:46 +08:00
|
|
|
if (!chip->enable_detection)
|
2011-03-01 08:55:28 +08:00
|
|
|
goto done;
|
|
|
|
|
2011-12-06 09:50:46 +08:00
|
|
|
if (!chip->gpio_detect &&
|
|
|
|
chip->is_present != (ret >= 0)) {
|
2020-05-14 02:56:04 +08:00
|
|
|
sbs_update_presence(chip, (ret >= 0));
|
2015-03-12 15:44:11 +08:00
|
|
|
power_supply_changed(chip->power_supply);
|
2011-03-01 08:55:28 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
done:
|
|
|
|
if (!ret) {
|
|
|
|
/* Convert units to match requirements for power supply class */
|
2011-12-06 09:50:46 +08:00
|
|
|
sbs_unit_adjustment(client, psp, val);
|
2011-03-01 08:55:28 +08:00
|
|
|
}
|
2010-09-22 06:33:55 +08:00
|
|
|
|
2010-09-06 06:31:23 +08:00
|
|
|
dev_dbg(&client->dev,
|
bq20z75: Fix issues with present and suspend
There are a few issues found around the battery not being present. If the
battery isn't present, then a few undesirable things happen. The first was
excessive reporting of failed properties. This was fixed by instead
returning ENODATA for all properties other than PRESENT if the battery
isn't present. That way the callers can identify the difference between a
failure and the battery not being there.
The next issue was in the suspend logic. It was found that if the battery
wasn't present, then it would return a failure, preventing the system from
going into suspend. If there is no battery present, the io is expected to
fail, so in that case, we shouldn't return the failure and just
acknowledge that it was expected.
I also found that when a gpio was used, i didn't maintain the internal
is_present state properly. I added a set of that to fix that.
Lastly, the code to see io's fail and figure out that the battery isn't
present when not using a gpio had a problem. In that code, it looked for
the read to fail and if it did, then handled it. The problem is that in
function to get the property, it first writes a value and that write can
fail, causing the code to never reach the logic after the read. Fix is
to move the logic till after the write.
Signed-off-by: Rhyland Klein <rklein@nvidia.com>
Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
2011-03-10 08:18:02 +08:00
|
|
|
"%s: property = %d, value = %x\n", __func__, psp, val->intval);
|
|
|
|
|
2011-12-06 09:50:46 +08:00
|
|
|
if (ret && chip->is_present)
|
bq20z75: Fix issues with present and suspend
There are a few issues found around the battery not being present. If the
battery isn't present, then a few undesirable things happen. The first was
excessive reporting of failed properties. This was fixed by instead
returning ENODATA for all properties other than PRESENT if the battery
isn't present. That way the callers can identify the difference between a
failure and the battery not being there.
The next issue was in the suspend logic. It was found that if the battery
wasn't present, then it would return a failure, preventing the system from
going into suspend. If there is no battery present, the io is expected to
fail, so in that case, we shouldn't return the failure and just
acknowledge that it was expected.
I also found that when a gpio was used, i didn't maintain the internal
is_present state properly. I added a set of that to fix that.
Lastly, the code to see io's fail and figure out that the battery isn't
present when not using a gpio had a problem. In that code, it looked for
the read to fail and if it did, then handled it. The problem is that in
function to get the property, it first writes a value and that write can
fail, causing the code to never reach the logic after the read. Fix is
to move the logic till after the write.
Signed-off-by: Rhyland Klein <rklein@nvidia.com>
Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
2011-03-10 08:18:02 +08:00
|
|
|
return ret;
|
|
|
|
|
|
|
|
/* battery not present, so return NODATA for properties */
|
|
|
|
if (ret)
|
|
|
|
return -ENODATA;
|
2010-09-06 06:31:23 +08:00
|
|
|
|
bq20z75: Fix issues with present and suspend
There are a few issues found around the battery not being present. If the
battery isn't present, then a few undesirable things happen. The first was
excessive reporting of failed properties. This was fixed by instead
returning ENODATA for all properties other than PRESENT if the battery
isn't present. That way the callers can identify the difference between a
failure and the battery not being there.
The next issue was in the suspend logic. It was found that if the battery
wasn't present, then it would return a failure, preventing the system from
going into suspend. If there is no battery present, the io is expected to
fail, so in that case, we shouldn't return the failure and just
acknowledge that it was expected.
I also found that when a gpio was used, i didn't maintain the internal
is_present state properly. I added a set of that to fix that.
Lastly, the code to see io's fail and figure out that the battery isn't
present when not using a gpio had a problem. In that code, it looked for
the read to fail and if it did, then handled it. The problem is that in
function to get the property, it first writes a value and that write can
fail, causing the code to never reach the logic after the read. Fix is
to move the logic till after the write.
Signed-off-by: Rhyland Klein <rklein@nvidia.com>
Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
2011-03-10 08:18:02 +08:00
|
|
|
return 0;
|
2010-09-06 06:31:23 +08:00
|
|
|
}
|
|
|
|
|
2017-05-01 16:49:58 +08:00
|
|
|
static void sbs_supply_changed(struct sbs_info *chip)
|
2011-03-01 08:55:28 +08:00
|
|
|
{
|
2016-07-25 10:42:58 +08:00
|
|
|
struct power_supply *battery = chip->power_supply;
|
2016-09-01 15:50:52 +08:00
|
|
|
int ret;
|
2011-03-01 08:55:28 +08:00
|
|
|
|
2016-09-01 15:50:52 +08:00
|
|
|
ret = gpiod_get_value_cansleep(chip->gpio_detect);
|
|
|
|
if (ret < 0)
|
2017-05-01 16:49:58 +08:00
|
|
|
return;
|
2020-05-14 02:56:04 +08:00
|
|
|
sbs_update_presence(chip, ret);
|
2011-03-01 08:55:28 +08:00
|
|
|
power_supply_changed(battery);
|
2017-05-01 16:49:58 +08:00
|
|
|
}
|
2011-03-01 08:55:28 +08:00
|
|
|
|
2017-05-01 16:49:58 +08:00
|
|
|
static irqreturn_t sbs_irq(int irq, void *devid)
|
|
|
|
{
|
|
|
|
sbs_supply_changed(devid);
|
2011-03-01 08:55:28 +08:00
|
|
|
return IRQ_HANDLED;
|
|
|
|
}
|
|
|
|
|
2017-05-01 16:49:58 +08:00
|
|
|
static void sbs_alert(struct i2c_client *client, enum i2c_alert_protocol prot,
|
|
|
|
unsigned int data)
|
|
|
|
{
|
|
|
|
sbs_supply_changed(i2c_get_clientdata(client));
|
|
|
|
}
|
|
|
|
|
2011-12-06 09:50:46 +08:00
|
|
|
static void sbs_external_power_changed(struct power_supply *psy)
|
2011-05-25 03:05:59 +08:00
|
|
|
{
|
2015-03-12 15:44:11 +08:00
|
|
|
struct sbs_info *chip = power_supply_get_drvdata(psy);
|
2011-05-25 03:05:59 +08:00
|
|
|
|
|
|
|
/* cancel outstanding work */
|
2011-12-06 09:50:46 +08:00
|
|
|
cancel_delayed_work_sync(&chip->work);
|
2011-05-25 03:05:59 +08:00
|
|
|
|
2011-12-06 09:50:46 +08:00
|
|
|
schedule_delayed_work(&chip->work, HZ);
|
2016-09-20 09:01:12 +08:00
|
|
|
chip->poll_time = chip->poll_retry_count;
|
2011-05-25 03:05:59 +08:00
|
|
|
}
|
|
|
|
|
2011-12-06 09:50:46 +08:00
|
|
|
static void sbs_delayed_work(struct work_struct *work)
|
2011-05-25 03:05:59 +08:00
|
|
|
{
|
2011-12-06 09:50:46 +08:00
|
|
|
struct sbs_info *chip;
|
2011-05-25 03:05:59 +08:00
|
|
|
s32 ret;
|
|
|
|
|
2011-12-06 09:50:46 +08:00
|
|
|
chip = container_of(work, struct sbs_info, work.work);
|
2011-05-25 03:05:59 +08:00
|
|
|
|
2011-12-06 09:50:46 +08:00
|
|
|
ret = sbs_read_word_data(chip->client, sbs_data[REG_STATUS].addr);
|
2011-05-25 03:05:59 +08:00
|
|
|
/* if the read failed, give up on this work */
|
|
|
|
if (ret < 0) {
|
2011-12-06 09:50:46 +08:00
|
|
|
chip->poll_time = 0;
|
2011-05-25 03:05:59 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (ret & BATTERY_FULL_CHARGED)
|
|
|
|
ret = POWER_SUPPLY_STATUS_FULL;
|
|
|
|
else if (ret & BATTERY_DISCHARGING)
|
|
|
|
ret = POWER_SUPPLY_STATUS_DISCHARGING;
|
|
|
|
else
|
|
|
|
ret = POWER_SUPPLY_STATUS_CHARGING;
|
|
|
|
|
2017-04-25 23:09:05 +08:00
|
|
|
sbs_status_correct(chip->client, &ret);
|
|
|
|
|
2011-12-06 09:50:46 +08:00
|
|
|
if (chip->last_state != ret) {
|
|
|
|
chip->poll_time = 0;
|
2015-03-12 15:44:11 +08:00
|
|
|
power_supply_changed(chip->power_supply);
|
2011-05-25 03:05:59 +08:00
|
|
|
return;
|
|
|
|
}
|
2011-12-06 09:50:46 +08:00
|
|
|
if (chip->poll_time > 0) {
|
|
|
|
schedule_delayed_work(&chip->work, HZ);
|
|
|
|
chip->poll_time--;
|
2011-05-25 03:05:59 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-03-12 15:44:11 +08:00
|
|
|
static const struct power_supply_desc sbs_default_desc = {
|
|
|
|
.type = POWER_SUPPLY_TYPE_BATTERY,
|
|
|
|
.properties = sbs_properties,
|
|
|
|
.num_properties = ARRAY_SIZE(sbs_properties),
|
|
|
|
.get_property = sbs_get_property,
|
|
|
|
.external_power_changed = sbs_external_power_changed,
|
|
|
|
};
|
|
|
|
|
2020-05-14 02:56:13 +08:00
|
|
|
static int sbs_probe(struct i2c_client *client)
|
2010-09-06 06:31:23 +08:00
|
|
|
{
|
2011-12-06 09:50:46 +08:00
|
|
|
struct sbs_info *chip;
|
2015-03-12 15:44:11 +08:00
|
|
|
struct power_supply_desc *sbs_desc;
|
2011-12-06 09:50:46 +08:00
|
|
|
struct sbs_platform_data *pdata = client->dev.platform_data;
|
2015-03-12 15:44:02 +08:00
|
|
|
struct power_supply_config psy_cfg = {};
|
2010-09-06 06:31:23 +08:00
|
|
|
int rc;
|
2011-03-01 08:55:28 +08:00
|
|
|
int irq;
|
2010-09-06 06:31:23 +08:00
|
|
|
|
2015-03-12 15:44:11 +08:00
|
|
|
sbs_desc = devm_kmemdup(&client->dev, &sbs_default_desc,
|
|
|
|
sizeof(*sbs_desc), GFP_KERNEL);
|
|
|
|
if (!sbs_desc)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
sbs_desc->name = devm_kasprintf(&client->dev, GFP_KERNEL, "sbs-%s",
|
|
|
|
dev_name(&client->dev));
|
|
|
|
if (!sbs_desc->name)
|
2010-09-06 06:31:23 +08:00
|
|
|
return -ENOMEM;
|
2011-12-06 09:50:49 +08:00
|
|
|
|
2016-07-25 10:42:57 +08:00
|
|
|
chip = devm_kzalloc(&client->dev, sizeof(struct sbs_info), GFP_KERNEL);
|
2015-03-12 15:44:11 +08:00
|
|
|
if (!chip)
|
|
|
|
return -ENOMEM;
|
2010-09-06 06:31:23 +08:00
|
|
|
|
2020-05-14 02:56:12 +08:00
|
|
|
chip->flags = (u32)(uintptr_t)device_get_match_data(&client->dev);
|
2011-12-06 09:50:46 +08:00
|
|
|
chip->client = client;
|
|
|
|
chip->enable_detection = false;
|
2015-03-12 15:44:02 +08:00
|
|
|
psy_cfg.of_node = client->dev.of_node;
|
2015-03-12 15:44:11 +08:00
|
|
|
psy_cfg.drv_data = chip;
|
2011-12-06 09:50:46 +08:00
|
|
|
chip->last_state = POWER_SUPPLY_STATUS_UNKNOWN;
|
2017-06-14 01:53:25 +08:00
|
|
|
mutex_init(&chip->mode_lock);
|
2010-09-06 06:31:23 +08:00
|
|
|
|
2016-09-06 21:16:33 +08:00
|
|
|
/* use pdata if available, fall back to DT properties,
|
|
|
|
* or hardcoded defaults if not
|
|
|
|
*/
|
2020-05-14 02:56:12 +08:00
|
|
|
rc = device_property_read_u32(&client->dev, "sbs,i2c-retry-count",
|
|
|
|
&chip->i2c_retry_count);
|
2016-09-06 21:16:33 +08:00
|
|
|
if (rc)
|
2016-09-20 09:01:12 +08:00
|
|
|
chip->i2c_retry_count = 0;
|
2016-09-06 21:16:33 +08:00
|
|
|
|
2020-05-14 02:56:12 +08:00
|
|
|
rc = device_property_read_u32(&client->dev, "sbs,poll-retry-count",
|
|
|
|
&chip->poll_retry_count);
|
2016-09-06 21:16:33 +08:00
|
|
|
if (rc)
|
|
|
|
chip->poll_retry_count = 0;
|
|
|
|
|
|
|
|
if (pdata) {
|
|
|
|
chip->poll_retry_count = pdata->poll_retry_count;
|
|
|
|
chip->i2c_retry_count = pdata->i2c_retry_count;
|
|
|
|
}
|
2016-09-20 09:01:12 +08:00
|
|
|
chip->i2c_retry_count = chip->i2c_retry_count + 1;
|
2011-09-15 04:19:07 +08:00
|
|
|
|
2020-05-14 02:56:12 +08:00
|
|
|
chip->charger_broadcasts = !device_property_read_bool(&client->dev,
|
2020-05-14 02:56:11 +08:00
|
|
|
"sbs,disable-charger-broadcasts");
|
|
|
|
|
2016-09-01 15:50:52 +08:00
|
|
|
chip->gpio_detect = devm_gpiod_get_optional(&client->dev,
|
|
|
|
"sbs,battery-detect", GPIOD_IN);
|
|
|
|
if (IS_ERR(chip->gpio_detect)) {
|
|
|
|
dev_err(&client->dev, "Failed to get gpio: %ld\n",
|
|
|
|
PTR_ERR(chip->gpio_detect));
|
|
|
|
return PTR_ERR(chip->gpio_detect);
|
2011-03-01 08:55:28 +08:00
|
|
|
}
|
|
|
|
|
2011-12-06 09:50:46 +08:00
|
|
|
i2c_set_clientdata(client, chip);
|
2010-09-06 06:31:23 +08:00
|
|
|
|
2011-12-06 09:50:46 +08:00
|
|
|
if (!chip->gpio_detect)
|
2011-03-01 08:55:28 +08:00
|
|
|
goto skip_gpio;
|
|
|
|
|
2016-09-01 15:50:52 +08:00
|
|
|
irq = gpiod_to_irq(chip->gpio_detect);
|
2011-03-01 08:55:28 +08:00
|
|
|
if (irq <= 0) {
|
|
|
|
dev_warn(&client->dev, "Failed to get gpio as irq: %d\n", irq);
|
|
|
|
goto skip_gpio;
|
|
|
|
}
|
|
|
|
|
2016-07-25 10:42:58 +08:00
|
|
|
rc = devm_request_threaded_irq(&client->dev, irq, NULL, sbs_irq,
|
2017-04-21 11:13:17 +08:00
|
|
|
IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
|
2016-07-25 10:42:58 +08:00
|
|
|
dev_name(&client->dev), chip);
|
2011-03-01 08:55:28 +08:00
|
|
|
if (rc) {
|
|
|
|
dev_warn(&client->dev, "Failed to request irq: %d\n", rc);
|
|
|
|
goto skip_gpio;
|
|
|
|
}
|
|
|
|
|
|
|
|
skip_gpio:
|
2012-09-07 02:32:29 +08:00
|
|
|
/*
|
sbs-battery: add option to always register battery
Commit a22b41a31e53 ("sbs-battery: Probe should try talking to the
device") introduced a step in probing the SBS battery, that tries to
talk to the device before actually registering it, saying:
this driver doesn't actually try talking to the device at probe
time, so if it's incorrectly configured in the device tree or
platform data (or if the battery has been removed from the system),
then probe will succeed and every access will sit there and time
out. The end result is a possibly laggy system that thinks it has a
battery but can never read status, which isn't very useful.
Which is of course reasonable. However, it is also very well possible
for a device to boot up on wall-power and be connected to a battery
later on. This is a scenario that the driver supported before said patch
was applied, and even easily achieved by booting up with the battery
attached and removing it later on. sbs-battery's 'present' sysfs file
can be used to determine if the device is available or not.
So with automated device detection lacking for now, in some cases it is
possible that one wants to register a battery, even if none are attached
at the moment. To facilitate this, add a module parameter that can be
used to configure forced loading module loading time. If set, the battery
will always be registered without checking the sanity of the connection.
Signed-off-by: Frans Klaver <frans.klaver@xsens.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
2015-06-10 20:16:56 +08:00
|
|
|
* Before we register, we might need to make sure we can actually talk
|
2012-09-07 02:32:29 +08:00
|
|
|
* to the battery.
|
|
|
|
*/
|
2016-09-01 15:50:52 +08:00
|
|
|
if (!(force_load || chip->gpio_detect)) {
|
sbs-battery: add option to always register battery
Commit a22b41a31e53 ("sbs-battery: Probe should try talking to the
device") introduced a step in probing the SBS battery, that tries to
talk to the device before actually registering it, saying:
this driver doesn't actually try talking to the device at probe
time, so if it's incorrectly configured in the device tree or
platform data (or if the battery has been removed from the system),
then probe will succeed and every access will sit there and time
out. The end result is a possibly laggy system that thinks it has a
battery but can never read status, which isn't very useful.
Which is of course reasonable. However, it is also very well possible
for a device to boot up on wall-power and be connected to a battery
later on. This is a scenario that the driver supported before said patch
was applied, and even easily achieved by booting up with the battery
attached and removing it later on. sbs-battery's 'present' sysfs file
can be used to determine if the device is available or not.
So with automated device detection lacking for now, in some cases it is
possible that one wants to register a battery, even if none are attached
at the moment. To facilitate this, add a module parameter that can be
used to configure forced loading module loading time. If set, the battery
will always be registered without checking the sanity of the connection.
Signed-off-by: Frans Klaver <frans.klaver@xsens.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
2015-06-10 20:16:56 +08:00
|
|
|
rc = sbs_read_word_data(client, sbs_data[REG_STATUS].addr);
|
|
|
|
|
|
|
|
if (rc < 0) {
|
|
|
|
dev_err(&client->dev, "%s: Failed to get device status\n",
|
|
|
|
__func__);
|
|
|
|
goto exit_psupply;
|
|
|
|
}
|
2012-09-07 02:32:29 +08:00
|
|
|
}
|
2011-03-01 08:55:28 +08:00
|
|
|
|
2016-07-25 10:42:59 +08:00
|
|
|
chip->power_supply = devm_power_supply_register(&client->dev, sbs_desc,
|
2015-03-12 15:44:11 +08:00
|
|
|
&psy_cfg);
|
|
|
|
if (IS_ERR(chip->power_supply)) {
|
2010-09-06 06:31:23 +08:00
|
|
|
dev_err(&client->dev,
|
|
|
|
"%s: Failed to register power supply\n", __func__);
|
2015-03-12 15:44:11 +08:00
|
|
|
rc = PTR_ERR(chip->power_supply);
|
2011-03-01 08:55:28 +08:00
|
|
|
goto exit_psupply;
|
2010-09-06 06:31:23 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
dev_info(&client->dev,
|
|
|
|
"%s: battery gas gauge device registered\n", client->name);
|
|
|
|
|
2011-12-06 09:50:46 +08:00
|
|
|
INIT_DELAYED_WORK(&chip->work, sbs_delayed_work);
|
2011-05-25 03:05:59 +08:00
|
|
|
|
2011-12-06 09:50:46 +08:00
|
|
|
chip->enable_detection = true;
|
2011-05-25 03:06:50 +08:00
|
|
|
|
2010-09-06 06:31:23 +08:00
|
|
|
return 0;
|
2011-03-01 08:55:28 +08:00
|
|
|
|
|
|
|
exit_psupply:
|
|
|
|
return rc;
|
2010-09-06 06:31:23 +08:00
|
|
|
}
|
|
|
|
|
2012-11-20 02:26:07 +08:00
|
|
|
static int sbs_remove(struct i2c_client *client)
|
2010-09-06 06:31:23 +08:00
|
|
|
{
|
2011-12-06 09:50:46 +08:00
|
|
|
struct sbs_info *chip = i2c_get_clientdata(client);
|
2010-09-06 06:31:23 +08:00
|
|
|
|
2011-12-06 09:50:46 +08:00
|
|
|
cancel_delayed_work_sync(&chip->work);
|
2011-05-25 03:05:59 +08:00
|
|
|
|
2010-09-06 06:31:23 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-03-10 21:34:07 +08:00
|
|
|
#if defined CONFIG_PM_SLEEP
|
|
|
|
|
|
|
|
static int sbs_suspend(struct device *dev)
|
2010-09-06 06:31:23 +08:00
|
|
|
{
|
2013-03-10 21:34:07 +08:00
|
|
|
struct i2c_client *client = to_i2c_client(dev);
|
2011-12-06 09:50:46 +08:00
|
|
|
struct sbs_info *chip = i2c_get_clientdata(client);
|
power: supply: sbs-battery: don't assume MANUFACTURER_DATA formats
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 continue to use the existing TI command behaviors, and we effectively
revert commit 17c6d3979e5b ("sbs-battery: make writes to
ManufacturerAccess optional") to again make these commands required.
[1] http://www.ti.com/lit/er/sluu265a/sluu265a.pdf
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Rhyland Klein <rklein@nvidia.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
2018-06-13 04:20:41 +08:00
|
|
|
int ret;
|
2010-09-06 06:31:23 +08:00
|
|
|
|
2011-12-06 09:50:46 +08:00
|
|
|
if (chip->poll_time > 0)
|
|
|
|
cancel_delayed_work_sync(&chip->work);
|
2011-05-25 03:05:59 +08:00
|
|
|
|
2020-05-14 02:56:01 +08:00
|
|
|
if (chip->flags & SBS_FLAGS_TI_BQ20ZX5) {
|
power: supply: sbs-battery: don't assume MANUFACTURER_DATA formats
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 continue to use the existing TI command behaviors, and we effectively
revert commit 17c6d3979e5b ("sbs-battery: make writes to
ManufacturerAccess optional") to again make these commands required.
[1] http://www.ti.com/lit/er/sluu265a/sluu265a.pdf
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Rhyland Klein <rklein@nvidia.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
2018-06-13 04:20:41 +08:00
|
|
|
/* Write to manufacturer access with sleep command. */
|
|
|
|
ret = sbs_write_word_data(client,
|
|
|
|
sbs_data[REG_MANUFACTURER_DATA].addr,
|
|
|
|
MANUFACTURER_ACCESS_SLEEP);
|
|
|
|
if (chip->is_present && ret < 0)
|
|
|
|
return ret;
|
|
|
|
}
|
2010-09-06 06:31:23 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
2013-03-10 21:34:07 +08:00
|
|
|
|
|
|
|
static SIMPLE_DEV_PM_OPS(sbs_pm_ops, sbs_suspend, NULL);
|
|
|
|
#define SBS_PM_OPS (&sbs_pm_ops)
|
|
|
|
|
2010-09-06 06:31:23 +08:00
|
|
|
#else
|
2013-03-10 21:34:07 +08:00
|
|
|
#define SBS_PM_OPS NULL
|
2010-09-06 06:31:23 +08:00
|
|
|
#endif
|
|
|
|
|
2011-12-06 09:50:46 +08:00
|
|
|
static const struct i2c_device_id sbs_id[] = {
|
2020-05-14 02:56:01 +08:00
|
|
|
{ "bq20z65", 0 },
|
2010-09-06 06:31:23 +08:00
|
|
|
{ "bq20z75", 0 },
|
2011-12-06 09:50:46 +08:00
|
|
|
{ "sbs-battery", 1 },
|
2010-09-06 06:31:23 +08:00
|
|
|
{}
|
|
|
|
};
|
2011-12-06 09:50:46 +08:00
|
|
|
MODULE_DEVICE_TABLE(i2c, sbs_id);
|
|
|
|
|
2016-09-06 21:16:33 +08:00
|
|
|
static const struct of_device_id sbs_dt_ids[] = {
|
|
|
|
{ .compatible = "sbs,sbs-battery" },
|
2020-05-14 02:56:01 +08:00
|
|
|
{
|
|
|
|
.compatible = "ti,bq20z65",
|
|
|
|
.data = (void *)SBS_FLAGS_TI_BQ20ZX5,
|
|
|
|
},
|
power: supply: sbs-battery: don't assume MANUFACTURER_DATA formats
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 continue to use the existing TI command behaviors, and we effectively
revert commit 17c6d3979e5b ("sbs-battery: make writes to
ManufacturerAccess optional") to again make these commands required.
[1] http://www.ti.com/lit/er/sluu265a/sluu265a.pdf
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Rhyland Klein <rklein@nvidia.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
2018-06-13 04:20:41 +08:00
|
|
|
{
|
|
|
|
.compatible = "ti,bq20z75",
|
2020-05-14 02:56:01 +08:00
|
|
|
.data = (void *)SBS_FLAGS_TI_BQ20ZX5,
|
power: supply: sbs-battery: don't assume MANUFACTURER_DATA formats
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 continue to use the existing TI command behaviors, and we effectively
revert commit 17c6d3979e5b ("sbs-battery: make writes to
ManufacturerAccess optional") to again make these commands required.
[1] http://www.ti.com/lit/er/sluu265a/sluu265a.pdf
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Rhyland Klein <rklein@nvidia.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
2018-06-13 04:20:41 +08:00
|
|
|
},
|
2016-09-06 21:16:33 +08:00
|
|
|
{ }
|
|
|
|
};
|
|
|
|
MODULE_DEVICE_TABLE(of, sbs_dt_ids);
|
|
|
|
|
2011-12-06 09:50:46 +08:00
|
|
|
static struct i2c_driver sbs_battery_driver = {
|
2020-05-14 02:56:13 +08:00
|
|
|
.probe_new = sbs_probe,
|
2012-11-20 02:20:40 +08:00
|
|
|
.remove = sbs_remove,
|
2017-05-01 16:49:58 +08:00
|
|
|
.alert = sbs_alert,
|
2011-12-06 09:50:46 +08:00
|
|
|
.id_table = sbs_id,
|
2010-09-06 06:31:23 +08:00
|
|
|
.driver = {
|
2011-12-06 09:50:46 +08:00
|
|
|
.name = "sbs-battery",
|
2016-09-06 21:16:33 +08:00
|
|
|
.of_match_table = sbs_dt_ids,
|
2013-03-10 21:34:07 +08:00
|
|
|
.pm = SBS_PM_OPS,
|
2010-09-06 06:31:23 +08:00
|
|
|
},
|
|
|
|
};
|
2012-01-21 14:42:54 +08:00
|
|
|
module_i2c_driver(sbs_battery_driver);
|
2010-09-06 06:31:23 +08:00
|
|
|
|
2011-12-06 09:50:46 +08:00
|
|
|
MODULE_DESCRIPTION("SBS battery monitor driver");
|
2010-09-06 06:31:23 +08:00
|
|
|
MODULE_LICENSE("GPL");
|
sbs-battery: add option to always register battery
Commit a22b41a31e53 ("sbs-battery: Probe should try talking to the
device") introduced a step in probing the SBS battery, that tries to
talk to the device before actually registering it, saying:
this driver doesn't actually try talking to the device at probe
time, so if it's incorrectly configured in the device tree or
platform data (or if the battery has been removed from the system),
then probe will succeed and every access will sit there and time
out. The end result is a possibly laggy system that thinks it has a
battery but can never read status, which isn't very useful.
Which is of course reasonable. However, it is also very well possible
for a device to boot up on wall-power and be connected to a battery
later on. This is a scenario that the driver supported before said patch
was applied, and even easily achieved by booting up with the battery
attached and removing it later on. sbs-battery's 'present' sysfs file
can be used to determine if the device is available or not.
So with automated device detection lacking for now, in some cases it is
possible that one wants to register a battery, even if none are attached
at the moment. To facilitate this, add a module parameter that can be
used to configure forced loading module loading time. If set, the battery
will always be registered without checking the sanity of the connection.
Signed-off-by: Frans Klaver <frans.klaver@xsens.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
2015-06-10 20:16:56 +08:00
|
|
|
|
2019-11-02 03:06:59 +08:00
|
|
|
module_param(force_load, bool, 0444);
|
sbs-battery: add option to always register battery
Commit a22b41a31e53 ("sbs-battery: Probe should try talking to the
device") introduced a step in probing the SBS battery, that tries to
talk to the device before actually registering it, saying:
this driver doesn't actually try talking to the device at probe
time, so if it's incorrectly configured in the device tree or
platform data (or if the battery has been removed from the system),
then probe will succeed and every access will sit there and time
out. The end result is a possibly laggy system that thinks it has a
battery but can never read status, which isn't very useful.
Which is of course reasonable. However, it is also very well possible
for a device to boot up on wall-power and be connected to a battery
later on. This is a scenario that the driver supported before said patch
was applied, and even easily achieved by booting up with the battery
attached and removing it later on. sbs-battery's 'present' sysfs file
can be used to determine if the device is available or not.
So with automated device detection lacking for now, in some cases it is
possible that one wants to register a battery, even if none are attached
at the moment. To facilitate this, add a module parameter that can be
used to configure forced loading module loading time. If set, the battery
will always be registered without checking the sanity of the connection.
Signed-off-by: Frans Klaver <frans.klaver@xsens.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
2015-06-10 20:16:56 +08:00
|
|
|
MODULE_PARM_DESC(force_load,
|
|
|
|
"Attempt to load the driver even if no battery is connected");
|