[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250713145810.31853bc7@jic23-huawei>
Date: Sun, 13 Jul 2025 14:58:10 +0100
From: Jonathan Cameron <jic23@...nel.org>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc: David Lechner <dlechner@...libre.com>, 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: sx9500: use stack allocated buffer for
scan data
On Sun, 13 Jul 2025 14:55:33 +0100
Jonathan Cameron <jic23@...nel.org> wrote:
> On Fri, 11 Jul 2025 19:42:25 +0300
> Andy Shevchenko <andriy.shevchenko@...ux.intel.com> wrote:
>
> > On Fri, Jul 11, 2025 at 10:47:57AM -0500, David Lechner wrote:
> > > Use IIO_DECLARE_BUFFER_WITH_TS() to declare a stack allocated buffer
> > > in sx9500_trigger_handler(). Since the scan buffer isn't used outside
> > > of this function, it doesn't need to be in struct sx9500_data.
> > >
> > > By always allocating enough space for the maximum number of channels,
> > > we can avoid having to reallocate the buffer each time buffered reads
> > > are enabled.
> >
> > Ag ood one!
> >
> > Reviewed-by: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
> >
>
> Applied.
>
Actually on second thoughts - why not a more descriptive structure?
There are only a max of 4 channels and so the timestamp is always
in the same location.
Dropped for now.
Jonathan
Powered by blists - more mailing lists