linux-kernel - Re: [PATCH 1/2] iio: temperature: mlx90632 Add supply regulator to sensor

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]

Message-ID: <20220806171345.45cf1228@jic23-huawei>
Date:   Sat, 6 Aug 2022 17:15:04 +0100
From:   Jonathan Cameron <jic23@...nel.org>
To:     Crt Mori <cmo@...exis.com>
Cc:     linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org,
        Lars-Peter Clausen <lars@...afoo.de>
Subject: Re: [PATCH 1/2] iio: temperature: mlx90632 Add supply regulator to
 sensor

On Tue,  2 Aug 2022 12:30:22 +0200
Crt Mori <cmo@...exis.com> wrote:

> Provide possibility to toggle power supply to the sensor so that user
> can optimize their setup and not have the sensor constantly powered.
> 
> Signed-off-by: Crt Mori <cmo@...exis.com>
> ---
>  drivers/iio/temperature/mlx90632.c | 52 ++++++++++++++++++++++++++++++
>  1 file changed, 52 insertions(+)
> 
> diff --git a/drivers/iio/temperature/mlx90632.c b/drivers/iio/temperature/mlx90632.c
> index 7ee7ff8047a4..e6e5e649a9f9 100644
> --- a/drivers/iio/temperature/mlx90632.c
> +++ b/drivers/iio/temperature/mlx90632.c
> @@ -18,6 +18,7 @@
>  #include <linux/math64.h>
>  #include <linux/pm_runtime.h>
>  #include <linux/regmap.h>
> +#include <linux/regulator/consumer.h>
>  
>  #include <linux/iio/iio.h>
>  #include <linux/iio/sysfs.h>
> @@ -128,6 +129,7 @@
>   *        calculations
>   * @object_ambient_temperature: Ambient temperature at object (might differ of
>   *                              the ambient temperature of sensor.
> + * @regulator: Regulator of the device
>   */
>  struct mlx90632_data {
>  	struct i2c_client *client;
> @@ -136,6 +138,7 @@ struct mlx90632_data {
>  	u16 emissivity;
>  	u8 mtyp;
>  	u32 object_ambient_temperature;
> +	struct regulator *regulator;
>  };
>  
>  static const struct regmap_range mlx90632_volatile_reg_range[] = {
> @@ -841,6 +844,37 @@ static int mlx90632_wakeup(struct mlx90632_data *data)
>  	return mlx90632_pwr_continuous(data->regmap);
>  }
>  
> +static void mlx90632_disable_regulator(void *_data)
> +{
> +	struct mlx90632_data *data = _data;
> +	int ret;
> +
> +	ret = regulator_disable(data->regulator);
> +	if (ret < 0)
> +		dev_err(regmap_get_device(data->regmap),
> +			"Failed to disable power regulator: %d\n", ret);
> +}
> +
> +static int mlx90632_enable_regulator(struct mlx90632_data *data)
> +{
> +	int ret;
> +
> +	ret = regulator_set_voltage(data->regulator, 3200000, 3600000);
> +	if (ret < 0) {

Hmm. This can be problematic, as a valid option is for the a stub regulator to
have been returned.  Mostly for device where it is common for them to be wired
to fixed regulators, we just assume the firmware set the voltage correctly.
Ideally it provides a fixed (or controllable) regulator to make that clear.

> +		dev_err(regmap_get_device(data->regmap), "Failed to set voltage on regulator!\n");
> +		return ret;
> +	}
> +
> +	ret = regulator_enable(data->regulator);
> +	if (ret < 0) {
> +		dev_err(regmap_get_device(data->regmap), "Failed to enable power regulator!\n");

Trivial style thing.  Obviously makes no difference functionally but it makes all error blocks look
similar whether they are at the end of a function or not which saves a few brain cells when reviewing
lots of code.

	if (ret < 0) {
		dev_err(); 
		return ret;
	}

	/* Give the device ... */
	msleep();

	return 0;
}
	
> +	} else {
> +		/* Give the device a little bit of time to start up. */
> +		msleep(MLX90632_SLEEP_DELAY_MS);
> +	}
> +	return ret;
> +}
> +
>  static int mlx90632_probe(struct i2c_client *client,
>  			  const struct i2c_device_id *id)
>  {
> @@ -876,6 +910,24 @@ static int mlx90632_probe(struct i2c_client *client,
>  	indio_dev->channels = mlx90632_channels;
>  	indio_dev->num_channels = ARRAY_SIZE(mlx90632_channels);
>  
> +	mlx90632->regulator = devm_regulator_get(&client->dev, "vdd");

An error here is a real error and should report it rather than carrying on.
May well be a case of deferring probe for example (use dev_err_probe() for the
reporting to handle that case nicely.

Note that if firmware doesn't provide a regulator we will get a dummy regulator
to represent the fact that we assume it just means no one bothered to specify
a fixed regulator in the firmware.  See drivers/regulator/dummy.c

> +	if (!IS_ERR(mlx90632->regulator)) {
> +		ret = mlx90632_enable_regulator(mlx90632);
> +		if (ret < 0) {
> +			dev_err(&client->dev, "Failed to enable regulator!\n");
> +			return ret;
> +		}
> +
> +		ret = devm_add_action_or_reset(&client->dev,
> +					       mlx90632_disable_regulator,
> +					       mlx90632);
> +		if (ret < 0) {
> +			dev_err(&client->dev, "Failed to setup regulator cleanup action %d\n",
> +				ret);
> +			return ret;
> +		}
> +	}
> +
>  	ret = mlx90632_wakeup(mlx90632);
>  	if (ret < 0) {
>  		dev_err(&client->dev, "Wakeup failed: %d\n", ret);