linux-kernel - Re: [PATCH v4 0/3] iio: temperature: mlx90632: Add powermanagement

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20220916161141.000069f5@huawei.com>
Date:   Fri, 16 Sep 2022 16:11:41 +0100
From:   Jonathan Cameron <Jonathan.Cameron@...wei.com>
To:     <cmo@...exis.com>
CC:     Jonathan Cameron <jic23@...nel.org>, <linux-iio@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>,
        Andy Shevchenko <andy.shevchenko@...il.com>
Subject: Re: [PATCH v4 0/3] iio: temperature: mlx90632: Add powermanagement

On Fri, 16 Sep 2022 12:45:49 +0200
cmo@...exis.com wrote:

> From: Crt Mori <cmo@...exis.com>
> 
> As discussed previously on the group under the
> "Controlling device power management from terminal" thread the mlx90632
> sensor provides measurement capabilities under sleep_step mode. This
> series runtime suspends the unused chip to sleep step mode to save power
> but in case of continuous sequential reading it switches to continuous
> mode for faster readouts. This value is hardcoded to
> MLX90632_MEAS_MAX_TIME (with some buffer) and not user configurable.
> 
> The sensor runtime suspension is set to MLX90632_SLEEP_DELAY_MS which is
> hardcoded to 3 times as much as MEAS_MAX_TIME.
> 
> Changes in v4 (per review comments from Jonathan Cameron):
> 
>  - Migrate back to devm_pm_runtime_enable and remove the pm_disable function
>  - Remove pm stuff from remove and also sleep, since when iio device is
>    not registered also sleep makes no sense.

Not sure the bit about sleep making no sense.  We normally try and
leave a device in as low power a state as possible when we unbind (just general
being nice to the environment etc!)

We might have cut the power to the device, but disabling the regulator
might not have that affect (fixed regulator for example) so it's normal
to put devices into a low power state before cutting the power (in case
it's not cut!)

Right now, this series may give someone a power regression...

Jonathan


>  - Replace use EOPNOTSUPP as per checkpatch suggestion although some drivers
>    still use ENOTSUPP.
>  - Change the style of read frequency
> 
> Changes in v3 (per review comments from Jonathan Cameron):
> 
>  - Change the "available" attribute presentation to more recent way
>    suggested
>  - Replace devm_pm_runtime_enable with enable and devm_add_action_or_reset
>  - When suspending device also put it to lower power mode in case there is
>    dummy regulator
>  - Use more switch cases instead of if/else
> 
> Changes in v2:
> 
>  - apply review comments from Andy Shevchenko
> 
> Crt Mori (3):
>   iio: temperature: mlx90632 Add runtime powermanagement modes
>   iio: temperature: mlx90632 Read sampling frequency
>   iio: temperature: mlx90632 Change return value of sensor measurement
>     channel
> 
>  drivers/iio/temperature/mlx90632.c | 402 +++++++++++++++++++++++++----
>  1 file changed, 347 insertions(+), 55 deletions(-)
>