* [PATCH 1/2] power: supply: bq27xxx_battery: Notify about all battery changes @ 2020-05-25 14:11 Krzysztof Kozlowski 2020-05-25 14:12 ` [PATCH 2/2] power: supply: bq27xxx_battery: Notify about voltage and current changes Krzysztof Kozlowski 2020-05-27 1:24 ` [PATCH 1/2] power: supply: bq27xxx_battery: Notify about all battery changes Andrew F. Davis 0 siblings, 2 replies; 7+ messages in thread From: Krzysztof Kozlowski @ 2020-05-25 14:11 UTC (permalink / raw) To: Andrew F. Davis, Pali Rohár, Sebastian Reichel, Krzysztof Kozlowski, linux-kernel, linux-pm Cc: 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 ^ permalink raw reply related [flat|nested] 7+ messages in thread
* [PATCH 2/2] power: supply: bq27xxx_battery: Notify about voltage and current changes 2020-05-25 14:11 [PATCH 1/2] power: supply: bq27xxx_battery: Notify about all battery changes Krzysztof Kozlowski @ 2020-05-25 14:12 ` Krzysztof Kozlowski 2020-05-27 1:24 ` [PATCH 1/2] power: supply: bq27xxx_battery: Notify about all battery changes Andrew F. Davis 1 sibling, 0 replies; 7+ messages in thread From: Krzysztof Kozlowski @ 2020-05-25 14:12 UTC (permalink / raw) To: Andrew F. Davis, Pali Rohár, Sebastian Reichel, Krzysztof Kozlowski, linux-kernel, linux-pm Cc: 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 ^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH 1/2] power: supply: bq27xxx_battery: Notify about all battery changes 2020-05-25 14:11 [PATCH 1/2] power: supply: bq27xxx_battery: Notify about all battery changes Krzysztof Kozlowski 2020-05-25 14:12 ` [PATCH 2/2] power: supply: bq27xxx_battery: Notify about voltage and current changes Krzysztof Kozlowski @ 2020-05-27 1:24 ` Andrew F. Davis 2020-05-27 7:22 ` Krzysztof Kozlowski 2020-06-16 10:52 ` Pavel Machek 1 sibling, 2 replies; 7+ messages in thread From: Andrew F. Davis @ 2020-05-27 1:24 UTC (permalink / raw) To: Krzysztof Kozlowski, Pali Rohár, Sebastian Reichel, Krzysztof Kozlowski, linux-kernel, linux-pm 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; > } > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 1/2] power: supply: bq27xxx_battery: Notify about all battery changes 2020-05-27 1:24 ` [PATCH 1/2] power: supply: bq27xxx_battery: Notify about all battery changes Andrew F. Davis @ 2020-05-27 7:22 ` Krzysztof Kozlowski 2020-05-27 7:30 ` Krzysztof Kozlowski 2020-06-16 10:52 ` Pavel Machek 1 sibling, 1 reply; 7+ messages in thread From: Krzysztof Kozlowski @ 2020-05-27 7:22 UTC (permalink / raw) To: Andrew F. Davis Cc: Pali Rohár, Sebastian Reichel, Krzysztof Kozlowski, linux-kernel, linux-pm 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; > > } > > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 1/2] power: supply: bq27xxx_battery: Notify about all battery changes 2020-05-27 7:22 ` Krzysztof Kozlowski @ 2020-05-27 7:30 ` Krzysztof Kozlowski 0 siblings, 0 replies; 7+ messages in thread From: Krzysztof Kozlowski @ 2020-05-27 7:30 UTC (permalink / raw) To: Andrew F. Davis Cc: Pali Rohár, Sebastian Reichel, Krzysztof Kozlowski, linux-kernel, linux-pm 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 1/2] power: supply: bq27xxx_battery: Notify about all battery changes 2020-05-27 1:24 ` [PATCH 1/2] power: supply: bq27xxx_battery: Notify about all battery changes Andrew F. Davis 2020-05-27 7:22 ` Krzysztof Kozlowski @ 2020-06-16 10:52 ` Pavel Machek 2020-06-16 11:57 ` Krzysztof Kozlowski 1 sibling, 1 reply; 7+ messages in thread From: Pavel Machek @ 2020-06-16 10:52 UTC (permalink / raw) To: Andrew F. Davis Cc: Krzysztof Kozlowski, Pali Roh??r, Sebastian Reichel, Krzysztof Kozlowski, linux-kernel, linux-pm 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 1/2] power: supply: bq27xxx_battery: Notify about all battery changes 2020-06-16 10:52 ` Pavel Machek @ 2020-06-16 11:57 ` Krzysztof Kozlowski 0 siblings, 0 replies; 7+ messages in thread From: Krzysztof Kozlowski @ 2020-06-16 11:57 UTC (permalink / raw) To: Pavel Machek Cc: Andrew F. Davis, Pali Roh??r, Sebastian Reichel, Krzysztof Kozlowski, linux-kernel, linux-pm 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2020-06-16 11:57 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-05-25 14:11 [PATCH 1/2] power: supply: bq27xxx_battery: Notify about all battery changes Krzysztof Kozlowski 2020-05-25 14:12 ` [PATCH 2/2] power: supply: bq27xxx_battery: Notify about voltage and current changes Krzysztof Kozlowski 2020-05-27 1:24 ` [PATCH 1/2] power: supply: bq27xxx_battery: Notify about all battery changes Andrew F. Davis 2020-05-27 7:22 ` Krzysztof Kozlowski 2020-05-27 7:30 ` Krzysztof Kozlowski 2020-06-16 10:52 ` Pavel Machek 2020-06-16 11:57 ` Krzysztof Kozlowski
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).