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: <a834e345-6d44-4fe6-a3ed-cc856e9dc4d3@baylibre.com>
Date: Sat, 19 Apr 2025 12:57:11 -0500
From: David Lechner <dlechner@...libre.com>
To: Andy Shevchenko <andy@...nel.org>
Cc: Jonathan Cameron <jic23@...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 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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ