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] [day] [month] [year] [list]

Date:   Sat, 6 Aug 2022 18:29:11 +0200
From:   Lars-Peter Clausen <lars@...afoo.de>
To:     Jonathan Cameron <jic23@...nel.org>, Crt Mori <cmo@...exis.com>
Cc:     linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] iio: temperature: mlx90632 Add supply regulator to
 sensor

On 8/6/22 18:15, Jonathan Cameron wrote:
> 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.

Just to add to what Jonathan said. For configurable regulators the 
allowed voltage values should be provided in the devicetree and the 
regulator framework will set it automatically. See the 
regulator-min-microvolt and regulator-max-microvolt DT properties.