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:   Thu, 15 Sep 2022 15:07:52 +0100
From:   Jonathan Cameron <jic23@...nel.org>
To:     cmo@...exis.com
Cc:     linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org,
        Andy Shevchenko <andy.shevchenko@...il.com>
Subject: Re: [PATCH v3 1/3] iio: temperature: mlx90632 Add runtime
 powermanagement modes

On Tue,  6 Sep 2022 11:04:30 +0200
cmo@...exis.com wrote:

> From: Crt Mori <cmo@...exis.com>
> 
> The sensor can operate in lower power modes and even make measurements when
> in those lower powered modes. The decision was taken that if measurement
> is not requested within 2 seconds the sensor will remain in SLEEP_STEP
> power mode, where measurements are triggered on request with setting the
> start of measurement bit (SOB). In this mode the measurements are taking
> a bit longer because we need to start it and complete it. Currently, in
> continuous mode we read ready data and this mode is activated if sensor
> measurement is requested within 2 seconds. The suspend timeout is
> increased to 6 seconds (instead of 3 before), because that enables more
> measurements in lower power mode (SLEEP_STEP), with the lowest refresh
> rate (2 seconds).
> 
> Signed-off-by: Crt Mori <cmo@...exis.com>

This is missing necessary disabling of autosuspend (see inline).

Also, I just realised you have the original pm disables in remove after
this patch - so effectively you disable runtime pm twice.

There is a sleep in that remove function which can also be done with
a devm_add_action_or_reset().  Do that as well and you can move
the device register to the devm form and drop the remove() function entirely.


> ---
>  drivers/iio/temperature/mlx90632.c | 347 +++++++++++++++++++++++++----
>  1 file changed, 302 insertions(+), 45 deletions(-)

> +	return 2;
> +}
> +

Nitpick, but single line is plenty.

> +
> +static int mlx90632_set_meas_type(struct mlx90632_data *data, u8 type)
> +{


>  
>  static int mlx90632_write_raw(struct iio_dev *indio_dev,
> @@ -875,6 +1096,15 @@ static int mlx90632_enable_regulator(struct mlx90632_data *data)
>  	return ret;
>  }
>  
> +static void mlx90632_pm_disable(void *data)
> +{
> +	struct device *dev = data;
> +
> +	pm_runtime_get_sync(dev);
So, this isn't quite enough.

Take a look at what devm_pm_runtime_enable()
does as the documentation for
pm_runtime_use_autosuspend()

I'd suggest using devm_pm_runtime_enable() and
an additional callback to turn the device on that
is registered after devm_pm_runtime_enable()
(so will maintain the ordering you have here).


 
> +	pm_runtime_put_noidle(dev);
> +	pm_runtime_disable(dev);
> +}
> +
>  static int mlx90632_probe(struct i2c_client *client,
>  			  const struct i2c_device_id *id)
>  {
> @@ -902,6 +1132,7 @@ static int mlx90632_probe(struct i2c_client *client,
>  	mlx90632->client = client;
>  	mlx90632->regmap = regmap;
>  	mlx90632->mtyp = MLX90632_MTYP_MEDICAL;
> +	mlx90632->powerstatus = MLX90632_PWR_STATUS_HALT;
>  
>  	mutex_init(&mlx90632->lock);
>  	indio_dev->name = id->name;
> @@ -961,16 +1192,25 @@ static int mlx90632_probe(struct i2c_client *client,
>  
>  	mlx90632->emissivity = 1000;
>  	mlx90632->object_ambient_temperature = 25000; /* 25 degrees milliCelsius */
> +	mlx90632->interaction_ts = jiffies; /* Set initial value */
>  
> -	pm_runtime_disable(&client->dev);
> +	pm_runtime_get_noresume(&client->dev);
>  	ret = pm_runtime_set_active(&client->dev);
>  	if (ret < 0) {
>  		mlx90632_sleep(mlx90632);
>  		return ret;
>  	}
> +
>  	pm_runtime_enable(&client->dev);
>  	pm_runtime_set_autosuspend_delay(&client->dev, MLX90632_SLEEP_DELAY_MS);
>  	pm_runtime_use_autosuspend(&client->dev);
> +	pm_runtime_put_autosuspend(&client->dev);
> +
> +	ret = devm_add_action_or_reset(&client->dev, mlx90632_pm_disable, &client->dev);

Having moved those over to devm you need to also have dropped the calls in remove()
(I only noticed this whilst trying to fix the autosuspend issue above.)
> +	if (ret) {
> +		mlx90632_sleep(mlx90632);
> +		return ret;
> +	}
>  
>  	return iio_device_register(indio_dev);
>  }

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ