linux-kernel - Re: [PATCH v4 2/7] iio: adc: ad4695: use u16 for buffer elements

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: <20250504181947.17072724@jic23-huawei>
Date: Sun, 4 May 2025 18:19:47 +0100
From: Jonathan Cameron <jic23@...nel.org>
To: Trevor Gamblin <tgamblin@...libre.com>
Cc: David Lechner <dlechner@...libre.com>, Nuno Sá
 <nuno.sa@...log.com>, Andy Shevchenko <andy@...nel.org>, Lars-Peter Clausen
 <lars@...afoo.de>, Michael Hennerich <Michael.Hennerich@...log.com>, Eugen
 Hristev <eugen.hristev@...aro.org>, Nicolas Ferre
 <nicolas.ferre@...rochip.com>, Alexandre Belloni
 <alexandre.belloni@...tlin.com>, Claudiu Beznea <claudiu.beznea@...on.dev>,
 linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v4 2/7] iio: adc: ad4695: use u16 for buffer elements

On Mon, 28 Apr 2025 16:33:21 -0400
Trevor Gamblin <tgamblin@...libre.com> wrote:

> On 2025-04-28 16:23, David Lechner wrote:
> > Change the type of the buffer elements to u16 since we currently only
> > support 16-bit word size. The code was originally written to also allow
> > for 32-bit word size when oversampling is enabled, but so far,
> > oversampling is only implemented when using SPI offload and therefore
> > doesn't use this buffer.
> >
> > AD4695_MAX_CHANNEL_SIZE macro is dropped since it no longer adds any
> > value.
> >
> > AD4695_MAX_CHANNELS + 2 is changed to AD4695_MAX_CHANNELS + 1 because
> > previously we were overallocating. AD4695_MAX_CHANNELS is the number of
> > of voltage channels and + 1 is for the temperature channel.
> >
> > Signed-off-by: David Lechner <dlechner@...libre.com>  
> Reviewed-by: Trevor Gamblin <tgamblin@...libre.com>
Mostly because there are two many patches for me to keep track of
at the moment I'm going to apply the ones in here that stand on their own
without the macro and your v5 with that size thing can be a smaller series :)

Applied this one.

Thanks,

Jonathan

> > ---
> >   drivers/iio/adc/ad4695.c | 9 +++------
> >   1 file changed, 3 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/iio/adc/ad4695.c b/drivers/iio/adc/ad4695.c
> > index 68c6625db0d75f4cade7cb029e94191118dbcaa0..0c633d43e480d5404074e9fa35f1d330b448f0a2 100644
> > --- a/drivers/iio/adc/ad4695.c
> > +++ b/drivers/iio/adc/ad4695.c
> > @@ -106,8 +106,6 @@
> >   
> >   /* Max number of voltage input channels. */
> >   #define AD4695_MAX_CHANNELS		16
> > -/* Max size of 1 raw sample in bytes. */
> > -#define AD4695_MAX_CHANNEL_SIZE		2
> >   
> >   enum ad4695_in_pair {
> >   	AD4695_IN_PAIR_REFGND,
> > @@ -162,8 +160,8 @@ struct ad4695_state {
> >   	struct spi_transfer buf_read_xfer[AD4695_MAX_CHANNELS * 2 + 3];
> >   	struct spi_message buf_read_msg;
> >   	/* Raw conversion data received. */
> > -	u8 buf[ALIGN((AD4695_MAX_CHANNELS + 2) * AD4695_MAX_CHANNEL_SIZE,
> > -		     sizeof(s64)) + sizeof(s64)] __aligned(IIO_DMA_MINALIGN);
> > +	u16 buf[ALIGN((AD4695_MAX_CHANNELS + 1) * sizeof(u16),
> > +		      sizeof(s64)) + sizeof(s64)] __aligned(IIO_DMA_MINALIGN);
> >   	u16 raw_data;
> >   	/* Commands to send for single conversion. */
> >   	u16 cnv_cmd;
> > @@ -660,9 +658,8 @@ static int ad4695_buffer_preenable(struct iio_dev *indio_dev)
> >   	iio_for_each_active_channel(indio_dev, bit) {
> >   		xfer = &st->buf_read_xfer[num_xfer];
> >   		xfer->bits_per_word = 16;
> > -		xfer->rx_buf = &st->buf[rx_buf_offset];
> > +		xfer->rx_buf = &st->buf[rx_buf_offset++];
> >   		xfer->len = 2;
> > -		rx_buf_offset += xfer->len;
> >   
> >   		if (bit == temp_chan_bit) {
> >   			temp_en = 1;
> >  
>