linux-kernel - Re: [PATCH v2] iio: adc: mt6360: Handle error in cleanup path correctly

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

Message-ID: <20251004153125.2e46b6ff@jic23-huawei>
Date: Sat, 4 Oct 2025 15:31:25 +0100
From: Jonathan Cameron <jic23@...nel.org>
To: Haotian Zhang <vulab@...as.ac.cn>
Cc: linux-iio@...r.kernel.org, Lars-Peter Clausen <lars@...afoo.de>,
 Matthias Brugger <matthias.bgg@...il.com>, AngeloGioacchino Del Regno
 <angelogioacchino.delregno@...labora.com>, Abhash Jha
 <abhashkumarjha123@...il.com>, Al Viro <viro@...iv.linux.org.uk>,
 linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
 linux-mediatek@...ts.infradead.org
Subject: Re: [PATCH v2] iio: adc: mt6360: Handle error in cleanup path
 correctly

On Tue, 30 Sep 2025 00:24:53 +0800
Haotian Zhang <vulab@...as.ac.cn> wrote:

> The return value of a regmap_raw_write() and regmap_update_bits()
> in the cleanup path was being ignored.
> 
> Fix this by checking the return value and warn on error.
> 
> Fixes: 1f4877218f7e ("iio: adc: mt6360: Add ADC driver for MT6360")
> Signed-off-by: Haotian Zhang <vulab@...as.ac.cn>
> 
> ---
> Changes in v2:
>  - Do not propagate cleanup path errors.
>  - Log a warning on failure instead of overwriting the return value, as
>    suggested by the maintainer.

As below. I think dev_err() is appropriate.

>  - Also check the return value of regmap_update_bits() for consistency.
> ---
>  drivers/iio/adc/mt6360-adc.c | 10 ++++++++--
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/iio/adc/mt6360-adc.c b/drivers/iio/adc/mt6360-adc.c
> index 69b3569c90e5..9ee7247aacbe 100644
> --- a/drivers/iio/adc/mt6360-adc.c
> +++ b/drivers/iio/adc/mt6360-adc.c
> @@ -70,6 +70,7 @@ static int mt6360_adc_read_channel(struct mt6360_adc_data *mad, int channel, int
>  	ktime_t predict_end_t, timeout;
>  	unsigned int pre_wait_time;
>  	int ret;
> +	int cleanup_ret;
>  
>  	mutex_lock(&mad->adc_lock);
>  
> @@ -130,11 +131,16 @@ static int mt6360_adc_read_channel(struct mt6360_adc_data *mad, int channel, int
>  out_adc_conv:
>  	/* Only keep ADC enable */
>  	adc_enable = cpu_to_be16(MT6360_ADCEN_MASK);
> -	regmap_raw_write(mad->regmap, MT6360_REG_PMUADCCFG, &adc_enable, sizeof(adc_enable));
> +	cleanup_ret = regmap_raw_write(mad->regmap, MT6360_REG_PMUADCCFG,
> +				&adc_enable, sizeof(adc_enable));
> +	if (cleanup_ret)
> +		dev_warn(mad->dev, "Failed to reset ADC config: %d\n", cleanup_ret);
Why warn? If this happens it's definite and error and may bite us later.

>  	mad->last_off_timestamps[channel] = ktime_get();
>  	/* Config prefer channel to NO_PREFER */
> -	regmap_update_bits(mad->regmap, MT6360_REG_PMUADCRPT1, MT6360_PREFERCH_MASK,
> +	cleanup_ret = regmap_update_bits(mad->regmap, MT6360_REG_PMUADCRPT1, MT6360_PREFERCH_MASK,
>  			   MT6360_NO_PREFER << MT6360_PREFERCH_SHFT);
> +	if (cleanup_ret)
> +		dev_warn(mad->dev, "Failed to reset prefer channel: %d\n", cleanup_ret);
>  out_adc_lock:
>  	mutex_unlock(&mad->adc_lock);
>  

Maybe it is worth trying to surface the error if nothing else has already gone wrong. That is a little fiddly
to do but something like

	if (cleanup_ret) {
		dev_err()
		ret = ret ?: cleanup_ret;
	}

I'm not sure it is worth the complexity however, so perhaps see if others have comments on this
in next few days before spinning a v3.

Thanks,

Jonathan