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