lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 27 May 2020 09:30:11 +0200
From:   Krzysztof Kozlowski <krzk@...nel.org>
To:     "Andrew F. Davis" <afd@...com>
Cc:     Pali Rohár <pali@...nel.org>,
        Sebastian Reichel <sre@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski@...ceq.com>,
        linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org
Subject: Re: [PATCH 1/2] power: supply: bq27xxx_battery: Notify about all
 battery changes

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ