linux-kernel - Re: [PATCH 2/4] iio: adc: ad4695: use IIO_DECLARE_BUFFER_WITH

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: <20250421135022.2ab97685@jic23-huawei>
Date: Mon, 21 Apr 2025 13:50:22 +0100
From: Jonathan Cameron <jic23@...nel.org>
To: David Lechner <dlechner@...libre.com>
Cc: Andy Shevchenko <andy@...nel.org>, Nuno Sá
 <nuno.sa@...log.com>, Lars-Peter Clausen <lars@...afoo.de>, Michael
 Hennerich <Michael.Hennerich@...log.com>, linux-iio@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/4] iio: adc: ad4695: use IIO_DECLARE_BUFFER_WITH_TS

On Sat, 19 Apr 2025 12:57:11 -0500
David Lechner <dlechner@...libre.com> wrote:

> On 4/19/25 11:38 AM, Andy Shevchenko wrote:
> > On Fri, Apr 18, 2025 at 05:58:33PM -0500, David Lechner wrote:  
> >> Use IIO_DECLARE_BUFFER_WITH_TS to declare the buffer that gets used with
> >> iio_push_to_buffers_with_ts(). This makes the code a bit easier to read
> >> and understand.
> >>
> >> AD4695_MAX_CHANNEL_SIZE macro is dropped since it was making the line
> >> too long and didn't add that much 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.  
> > 
> > ...
> >   
> >> -/* Max size of 1 raw sample in bytes. */
> >> -#define AD4695_MAX_CHANNEL_SIZE		2  
> >   
> >>  	/* Raw conversion data received. */
> >> -	u8 buf[ALIGN((AD4695_MAX_CHANNELS + 2) * AD4695_MAX_CHANNEL_SIZE,
> >> -		     sizeof(s64)) + sizeof(s64)] __aligned(IIO_DMA_MINALIGN);
> >> +	IIO_DECLARE_BUFFER_WITH_TS(u8, buf, (AD4695_MAX_CHANNELS + 1) * 2)
> >> +		__aligned(IIO_DMA_MINALIGN);  
> > 
> > I would rather expect this to be properly written as u16 / __le16 / __be16
> > instead of playing tricks with u8.
> > 
> > With all comments given so far I would expect here something like:
> > 
> > 	IIO_DECLARE_BUFFER_WITH_TS(u16, buf, AD4695_MAX_CHANNELS + 1);
> > 
> >   
> 
> We would have to make significant changes to the driver to allow u16 instead
> of u8. I don't remember why I did it that way in the first place, but I consider
> changing it out of scope for this patch.

There are drivers where the size varies depending on the exact part.
Maybe this is a cut and paste from one of those or you thought this might get
bigger to support > 16bit channels in the future.  Either way, right now
it is always 16 bits so an appropriately sized type would be good as you
say.   I think such a change should be in a precursor patch probably
rather than left for another day.  Looks trivial to me given st->buf
is only accessed directly in 2 places.

Jonathan