linux-kernel - Re: [PATCH 2/6] iio: adc: ti-adc128s052: Fix ADC value on BE systems

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: <20250331121124.4fed1d44@jic23-huawei>
Date: Mon, 31 Mar 2025 12:11:24 +0100
From: Jonathan Cameron <jic23@...nel.org>
To: Matti Vaittinen <mazziesaccount@...il.com>
Cc: Matti Vaittinen <matti.vaittinen@...rohmeurope.com>, Lars-Peter Clausen
 <lars@...afoo.de>, Rob Herring <robh@...nel.org>, Krzysztof Kozlowski
 <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, Nuno Sa
 <nuno.sa@...log.com>, David Lechner <dlechner@...libre.com>, Javier
 Carrasco <javier.carrasco.cruz@...il.com>, linux-iio@...r.kernel.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/6] iio: adc: ti-adc128s052: Fix ADC value on BE
 systems

On Mon, 31 Mar 2025 11:02:55 +0300
Matti Vaittinen <mazziesaccount@...il.com> wrote:

> ADCs supported by the ti-adc128s052 driver do return the ADC data in 16
> bits using big-endian format. The driver does unconditionally swap the
> bytes. This leads to wrong values being reported to users on big endian
> systems.
> 
> Fix this by using the be16_to_cpu() instead of doing unconditional byte
> swapping.

It's not doing unconditional byte swap that I can see. The
adc->buffer[0] << 8 | adc->buffer[1]
will work on big or little endian systems as we are explicitly saying
which byte represents higher bit values in a 16 bit output so on little
endian it's a byte swap, but on big endian it's a noop (the compiler might
noticed that and replace this code sequence with an assignment)

Good cleanup, but not a fix as such unless I'm missing something.
> 
> Fixes: 913b86468674 ("iio: adc: Add TI ADC128S052")
> Cc: stable@...r.kernel.org
> Signed-off-by: Matti Vaittinen <mazziesaccount@...il.com>
> ---
> I have no big endian machines on my hands to test this. Problem was
> spotted by reading the code, which leaves some room for errors.
> Careful reviewing is appreciated!
> ---
>  drivers/iio/adc/ti-adc128s052.c | 13 +++++++------
>  1 file changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/iio/adc/ti-adc128s052.c b/drivers/iio/adc/ti-adc128s052.c
> index a456ea78462f..d1e31122ea0d 100644
> --- a/drivers/iio/adc/ti-adc128s052.c
> +++ b/drivers/iio/adc/ti-adc128s052.c
> @@ -28,19 +28,20 @@ struct adc128 {
>  	struct regulator *reg;
>  	struct mutex lock;
>  
> -	u8 buffer[2] __aligned(IIO_DMA_MINALIGN);
> +	__be16 buffer __aligned(IIO_DMA_MINALIGN);
>  };
>  
>  static int adc128_adc_conversion(struct adc128 *adc, u8 channel)
>  {
>  	int ret;
> +	char *msg = (char *)&adc->buffer;
>  
> -	mutex_lock(&adc->lock);
> +	msg[0] = channel << 3;
> +	msg[1] = 0;

Given you are writing shared state why move this out of the lock?
Whilst here maybe using guard() would clean this driver up a little.


Use a separate buffer (or a union) so we can avoid the casting here

>  
> -	adc->buffer[0] = channel << 3;
> -	adc->buffer[1] = 0;
> +	mutex_lock(&adc->lock);
>  
> -	ret = spi_write(adc->spi, &adc->buffer, 2);
> +	ret = spi_write(adc->spi, msg, 2);

Given you are tidying this up, lets make the source of that size value obvious.

sizeof(adc->buffer)

>  	if (ret < 0) {
>  		mutex_unlock(&adc->lock);
>  		return ret;
> @@ -53,7 +54,7 @@ static int adc128_adc_conversion(struct adc128 *adc, u8 channel)
>  	if (ret < 0)
>  		return ret;
>  
> -	return ((adc->buffer[0] << 8 | adc->buffer[1]) & 0xFFF);
> +	return be16_to_cpu(adc->buffer) & 0xFFF;
>  }
>  
>  static int adc128_read_raw(struct iio_dev *indio_dev,