[PATCH 1/2] power: supply: bq27xxx_battery: Notify about all battery changes

[PATCH 1/2] power: supply: bq27xxx_battery: Notify about all battery changes

[Krzysztof Kozlowski]

All battery related data could be important for user-space.  For example
time-to-full could be shown to user on the screen or health could be
monitored for any issues.  Instead of comparing few selected old/new
values, just check if anything changed in the cache.

Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
 drivers/power/supply/bq27xxx_battery.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/power/supply/bq27xxx_battery.c b/drivers/power/supply/bq27xxx_battery.c
index 942c92127b6d..33c26d42cd02 100644
--- a/drivers/power/supply/bq27xxx_battery.c
+++ b/drivers/power/supply/bq27xxx_battery.c
@@ -1612,12 +1612,10 @@ void bq27xxx_battery_update(struct bq27xxx_device_info *di)
 			di->charge_design_full = bq27xxx_battery_read_dcap(di);
 	}
 
-	if ((di->cache.capacity != cache.capacity) ||
-	    (di->cache.flags != cache.flags))
+	if (memcmp(&di->cache, &cache, sizeof(cache)) != 0) {
 		power_supply_changed(di->bat);
-
-	if (memcmp(&di->cache, &cache, sizeof(cache)) != 0)
 		di->cache = cache;
+	}
 
 	di->last_update = jiffies;
 }
-- 
2.17.1

[PATCH 2/2] power: supply: bq27xxx_battery: Notify about voltage and current changes

[Krzysztof Kozlowski]

Read voltage and current and store them in the cache (like other
properties).  This has benefits:
1. User-space will be notified on voltage or current change.  These
   are important properties of charging so user-space might be
   interested in getting them.
2. Closes possible resource exhaustion attack through continuous I2C
   reads triggered by unprivileged power supply sysfs API.  User could
   just keep reading voltage_now or current_now sysfs entries leading
   to excessive I2C transfers.

Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
 drivers/power/supply/bq27xxx_battery.c | 97 ++++++++++++--------------
 include/linux/power/bq27xxx_battery.h  |  2 +
 2 files changed, 48 insertions(+), 51 deletions(-)

diff --git a/drivers/power/supply/bq27xxx_battery.c b/drivers/power/supply/bq27xxx_battery.c
index 33c26d42cd02..048618c13e17 100644
--- a/drivers/power/supply/bq27xxx_battery.c
+++ b/drivers/power/supply/bq27xxx_battery.c
@@ -1520,6 +1520,48 @@ static int bq27xxx_battery_read_pwr_avg(struct bq27xxx_device_info *di)
 		return tval;
 }
 
+/*
+ * Return the battery average current in µA
+ * Note that current can be negative signed as well
+ * Or 0 if something fails.
+ */
+static int bq27xxx_battery_read_current(struct bq27xxx_device_info *di,
+					int flags)
+{
+	int curr;
+
+	curr = bq27xxx_read(di, BQ27XXX_REG_AI, false);
+	if (curr < 0) {
+		dev_err(di->dev, "error reading current\n");
+		return 0;
+	}
+
+	if (di->opts & BQ27XXX_O_ZERO) {
+		if (flags & BQ27000_FLAG_CHGS) {
+			dev_dbg(di->dev, "negative current!\n");
+			curr = -curr;
+		}
+
+		return curr * BQ27XXX_CURRENT_CONSTANT / BQ27XXX_RS;
+	}
+
+	/* else: Other gauges return signed value */
+	return (int)((s16)curr) * 1000;
+}
+
+static int bq27xxx_battery_read_voltage(struct bq27xxx_device_info *di)
+{
+	int volt;
+
+	volt = bq27xxx_read(di, BQ27XXX_REG_VOLT, false);
+	if (volt < 0) {
+		dev_err(di->dev, "error reading voltage\n");
+		return volt;
+	}
+
+	return volt * 1000;
+}
+
 /*
  * Returns true if a battery over temperature condition is detected
  */
@@ -1606,6 +1648,8 @@ void bq27xxx_battery_update(struct bq27xxx_device_info *di)
 			cache.cycle_count = bq27xxx_battery_read_cyct(di);
 		if (di->regs[BQ27XXX_REG_AP] != INVALID_REG_ADDR)
 			cache.power_avg = bq27xxx_battery_read_pwr_avg(di);
+		cache.curr = bq27xxx_battery_read_current(di, cache.flags);
+		cache.voltage = bq27xxx_battery_read_voltage(di);
 
 		/* We only have to read charge design full once */
 		if (di->charge_design_full <= 0)
@@ -1633,39 +1677,6 @@ static void bq27xxx_battery_poll(struct work_struct *work)
 		schedule_delayed_work(&di->work, poll_interval * HZ);
 }
 
-/*
- * Return the battery average current in µA
- * Note that current can be negative signed as well
- * Or 0 if something fails.
- */
-static int bq27xxx_battery_current(struct bq27xxx_device_info *di,
-				   union power_supply_propval *val)
-{
-	int curr;
-	int flags;
-
-	curr = bq27xxx_read(di, BQ27XXX_REG_AI, false);
-	if (curr < 0) {
-		dev_err(di->dev, "error reading current\n");
-		return curr;
-	}
-
-	if (di->opts & BQ27XXX_O_ZERO) {
-		flags = bq27xxx_read(di, BQ27XXX_REG_FLAGS, true);
-		if (flags & BQ27000_FLAG_CHGS) {
-			dev_dbg(di->dev, "negative current!\n");
-			curr = -curr;
-		}
-
-		val->intval = curr * BQ27XXX_CURRENT_CONSTANT / BQ27XXX_RS;
-	} else {
-		/* Other gauges return signed value */
-		val->intval = (int)((s16)curr) * 1000;
-	}
-
-	return 0;
-}
-
 static int bq27xxx_battery_status(struct bq27xxx_device_info *di,
 				  union power_supply_propval *val)
 {
@@ -1728,22 +1739,6 @@ static int bq27xxx_battery_capacity_level(struct bq27xxx_device_info *di,
  * Return the battery Voltage in millivolts
  * Or < 0 if something fails.
  */
-static int bq27xxx_battery_voltage(struct bq27xxx_device_info *di,
-				   union power_supply_propval *val)
-{
-	int volt;
-
-	volt = bq27xxx_read(di, BQ27XXX_REG_VOLT, false);
-	if (volt < 0) {
-		dev_err(di->dev, "error reading voltage\n");
-		return volt;
-	}
-
-	val->intval = volt * 1000;
-
-	return 0;
-}
-
 static int bq27xxx_simple_value(int value,
 				union power_supply_propval *val)
 {
@@ -1777,13 +1772,13 @@ static int bq27xxx_battery_get_property(struct power_supply *psy,
 		ret = bq27xxx_battery_status(di, val);
 		break;
 	case POWER_SUPPLY_PROP_VOLTAGE_NOW:
-		ret = bq27xxx_battery_voltage(di, val);
+		ret = bq27xxx_simple_value(di->cache.voltage, val);
 		break;
 	case POWER_SUPPLY_PROP_PRESENT:
 		val->intval = di->cache.flags < 0 ? 0 : 1;
 		break;
 	case POWER_SUPPLY_PROP_CURRENT_NOW:
-		ret = bq27xxx_battery_current(di, val);
+		val->intval = di->cache.curr; /* Can be negative */
 		break;
 	case POWER_SUPPLY_PROP_CAPACITY:
 		ret = bq27xxx_simple_value(di->cache.capacity, val);
diff --git a/include/linux/power/bq27xxx_battery.h b/include/linux/power/bq27xxx_battery.h
index 507c5e214c42..418ba5e4029a 100644
--- a/include/linux/power/bq27xxx_battery.h
+++ b/include/linux/power/bq27xxx_battery.h
@@ -49,6 +49,8 @@ struct bq27xxx_reg_cache {
 	int cycle_count;
 	int capacity;
 	int energy;
+	int curr;
+	int voltage;
 	int flags;
 	int power_avg;
 	int health;
-- 
2.17.1

Re: [PATCH 1/2] power: supply: bq27xxx_battery: Notify about all battery changes

[Andrew F. Davis]

On 5/25/20 10:11 AM, Krzysztof Kozlowski wrote:
> All battery related data could be important for user-space.  For example
> time-to-full could be shown to user on the screen or health could be
> monitored for any issues.  Instead of comparing few selected old/new
> values, just check if anything changed in the cache.
> 


At least some value will change every time we poll the battery, are we
okay with having power_supply_changed() called every time?

Andrew


> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> ---
>  drivers/power/supply/bq27xxx_battery.c | 6 ++----
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/power/supply/bq27xxx_battery.c b/drivers/power/supply/bq27xxx_battery.c
> index 942c92127b6d..33c26d42cd02 100644
> --- a/drivers/power/supply/bq27xxx_battery.c
> +++ b/drivers/power/supply/bq27xxx_battery.c
> @@ -1612,12 +1612,10 @@ void bq27xxx_battery_update(struct bq27xxx_device_info *di)
>  			di->charge_design_full = bq27xxx_battery_read_dcap(di);
>  	}
>  
> -	if ((di->cache.capacity != cache.capacity) ||
> -	    (di->cache.flags != cache.flags))
> +	if (memcmp(&di->cache, &cache, sizeof(cache)) != 0) {
>  		power_supply_changed(di->bat);
> -
> -	if (memcmp(&di->cache, &cache, sizeof(cache)) != 0)
>  		di->cache = cache;
> +	}
>  
>  	di->last_update = jiffies;
>  }
> 

Re: [PATCH 1/2] power: supply: bq27xxx_battery: Notify about all battery changes

[Krzysztof Kozlowski]

On Tue, May 26, 2020 at 09:24:39PM -0400, Andrew F. Davis wrote:
> On 5/25/20 10:11 AM, Krzysztof Kozlowski wrote:
> > All battery related data could be important for user-space.  For example
> > time-to-full could be shown to user on the screen or health could be
> > monitored for any issues.  Instead of comparing few selected old/new
> > values, just check if anything changed in the cache.
> > 
> 
> 
> At least some value will change every time we poll the battery, are we
> okay with having power_supply_changed() called every time?

Hi,

Let me give few arguments:
1. "Every time" means still once per poll interval or in case of many
   get_property() calls, once per 5 seconds. In first case, if users
   sets polling every 1 second, I expect he knows what he wants. I2C
   will be busy anyway so uevents should not matter that much.
   In second case, called through get_property(), once per 5 seconds is
   not that frequent.

2. Different drivers do it differently. Many chargers notify about
   everything. Most fuel gauges only on status or capacity change (although
   I am not sure if they measure more) but few FG send uevents about
   everything (max17042_battery, sbs-battery, s3c_adc_battery).

3. If drivers does not send notifications on changed properties of
   battery, then basically the user-space has to poll every time for all
   data which is not being a trigger.  The overhead for system would be
   the same, I guess.

Best regards,
Krzysztof


> Andrew
> 
> 
> > Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> > ---
> >  drivers/power/supply/bq27xxx_battery.c | 6 ++----
> >  1 file changed, 2 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/power/supply/bq27xxx_battery.c b/drivers/power/supply/bq27xxx_battery.c
> > index 942c92127b6d..33c26d42cd02 100644
> > --- a/drivers/power/supply/bq27xxx_battery.c
> > +++ b/drivers/power/supply/bq27xxx_battery.c
> > @@ -1612,12 +1612,10 @@ void bq27xxx_battery_update(struct bq27xxx_device_info *di)
> >  			di->charge_design_full = bq27xxx_battery_read_dcap(di);
> >  	}
> >  
> > -	if ((di->cache.capacity != cache.capacity) ||
> > -	    (di->cache.flags != cache.flags))
> > +	if (memcmp(&di->cache, &cache, sizeof(cache)) != 0) {
> >  		power_supply_changed(di->bat);
> > -
> > -	if (memcmp(&di->cache, &cache, sizeof(cache)) != 0)
> >  		di->cache = cache;
> > +	}
> >  
> >  	di->last_update = jiffies;
> >  }
> > 

Re: [PATCH 1/2] power: supply: bq27xxx_battery: Notify about all battery changes

[Krzysztof Kozlowski]

On Wed, May 27, 2020 at 09:22:24AM +0200, Krzysztof Kozlowski wrote:
> On Tue, May 26, 2020 at 09:24:39PM -0400, Andrew F. Davis wrote:
> > On 5/25/20 10:11 AM, Krzysztof Kozlowski wrote:
> > > All battery related data could be important for user-space.  For example
> > > time-to-full could be shown to user on the screen or health could be
> > > monitored for any issues.  Instead of comparing few selected old/new
> > > values, just check if anything changed in the cache.
> > > 
> > 
> > 
> > At least some value will change every time we poll the battery, are we
> > okay with having power_supply_changed() called every time?
> 
> Hi,
> 
> Let me give few arguments:
> 1. "Every time" means still once per poll interval or in case of many
>    get_property() calls, once per 5 seconds. In first case, if users
>    sets polling every 1 second, I expect he knows what he wants. I2C
>    will be busy anyway so uevents should not matter that much.
>    In second case, called through get_property(), once per 5 seconds is
>    not that frequent.
> 
> 2. Different drivers do it differently. Many chargers notify about
>    everything. Most fuel gauges only on status or capacity change (although
>    I am not sure if they measure more) but few FG send uevents about
>    everything (max17042_battery, sbs-battery, s3c_adc_battery).
> 
> 3. If drivers does not send notifications on changed properties of
>    battery, then basically the user-space has to poll every time for all
>    data which is not being a trigger.  The overhead for system would be
>    the same, I guess.
> 

And one more:
4. I actually needed for my project. I have a user-space which
   previously was polling the battery status but I converted it to udev
   events.  The voltage, current and temperature are important for me as
   well so I need all uevents.

Best regards,
Krzysztof

Re: [PATCH 1/2] power: supply: bq27xxx_battery: Notify about all battery changes

[Pavel Machek]

On Tue 2020-05-26 21:24:39, Andrew F. Davis wrote:
> On 5/25/20 10:11 AM, Krzysztof Kozlowski wrote:
> > All battery related data could be important for user-space.  For example
> > time-to-full could be shown to user on the screen or health could be
> > monitored for any issues.  Instead of comparing few selected old/new
> > values, just check if anything changed in the cache.
> > 
> 
> 
> At least some value will change every time we poll the battery, are we
> okay with having power_supply_changed() called every time?

I believe that's very bad idea. AFAICT that would wake up userspace every
5 seconds, eating power in unexpected way, and without easy ability of opting
out. IOW a regression.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH 1/2] power: supply: bq27xxx_battery: Notify about all battery changes

[Krzysztof Kozlowski]

On Tue, Jun 16, 2020 at 12:52:24PM +0200, Pavel Machek wrote:
> On Tue 2020-05-26 21:24:39, Andrew F. Davis wrote:
> > On 5/25/20 10:11 AM, Krzysztof Kozlowski wrote:
> > > All battery related data could be important for user-space.  For example
> > > time-to-full could be shown to user on the screen or health could be
> > > monitored for any issues.  Instead of comparing few selected old/new
> > > values, just check if anything changed in the cache.
> > > 
> > 
> > 
> > At least some value will change every time we poll the battery, are we
> > okay with having power_supply_changed() called every time?
> 
> I believe that's very bad idea. AFAICT that would wake up userspace every
> 5 seconds, eating power in unexpected way, and without easy ability of opting
> out. IOW a regression.

It won't be 5 seconds but poll_interval which is 360 seconds by default.
It can be 5 seconds if user-space changes this time or if user-space
keeps asking for get_property. In first case: user-space kind of decided
about it... In second: user-space is already woken-up since it polls get
properties.

However I understand that this is quite intrusive change and maybe in
such case user-space should just keep polling (if it wants all data to
be provided every n-seconds).

Best regards,
Krzysztof