linux-kernel - Re: [PATCH] iio: proximity: srf08: use stack allocated scan buffer

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: <20250713150151.17c02007@jic23-huawei>
Date: Sun, 13 Jul 2025 15:01:51 +0100
From: Jonathan Cameron <jic23@...nel.org>
To: David Lechner <dlechner@...libre.com>
Cc: Andy Shevchenko <andriy.shevchenko@...el.com>, Andreas Klinger
 <ak@...klinger.de>, Nuno Sá <nuno.sa@...log.com>, Andy
 Shevchenko <andy@...nel.org>, linux-iio@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH] iio: proximity: srf08: use stack allocated scan buffer

On Fri, 11 Jul 2025 12:07:10 -0500
David Lechner <dlechner@...libre.com> wrote:

> On 7/11/25 11:44 AM, Andy Shevchenko wrote:
> > On Fri, Jul 11, 2025 at 11:07:20AM -0500, David Lechner wrote:  
> >> Use a stack allocated scan struct in srf08_trigger_handler(). Since the
> >> scan buffer isn't used outside of this function and doesn't need to be
> >> DMA-safe, it doesn't need to be in struct srf08_data. We can also
> >> eliminate an extra local variable for the return value of
> >> srf08_read_ranging() by using scan.chan directly.  
> > 
> > Why not with macro?
> >   
> 
> In cases like this where there are a fixed number of data values
> read, the existing pattern is to use the struct like this. Furthermore,
> IIO_DECLARE_BUFFER_WITH_TS() implies an array and usually we try to avoid
> arrays with only one element.
> 

I'd go a little further and say that to me structures are appropriate
even with multiple channels as long as they location of channels that
we are naming differently doesn't change.  That normally (but not always)
means the timestamp channel as the other channels tend to have the same
type.  So in practice if the channels take up 8 bytes or less before
the timestamp.

Jonathan