linux-kernel - Re: [PATCH 1/9] iio: imu: st_lsm6dsx: dynamically initialize iio_chan

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] [day] [month] [year] [list]

Message-ID: <20251109133252.1ae632b5@jic23-huawei>
Date: Sun, 9 Nov 2025 13:32:52 +0000
From: Jonathan Cameron <jic23@...nel.org>
To: Francesco Lavra <flavra@...libre.com>
Cc: Lorenzo Bianconi <lorenzo@...nel.org>, 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 1/9] iio: imu: st_lsm6dsx: dynamically initialize
 iio_chan_spec data

On Mon, 03 Nov 2025 10:24:54 +0100
Francesco Lavra <flavra@...libre.com> wrote:

> On Sun, 2025-11-02 at 11:16 +0000, Jonathan Cameron wrote:
> > On Thu, 30 Oct 2025 08:27:44 +0100
> > Francesco Lavra <flavra@...libre.com> wrote:
> >   
> > > Using the ST_LSM6DSX_CHANNEL_ACC() macro as a static initializer
> > > for the iio_chan_spec struct arrays makes all sensors advertise
> > > channel event capabilities regardless of whether they actually
> > > support event generation. And if userspace tries to configure
> > > accelerometer wakeup events on a sensor device that does not
> > > support them (e.g. LSM6DS0), st_lsm6dsx_write_event() dereferences
> > > a NULL pointer when trying to write to the wakeup register.
> > > Replace usage of the ST_LSM6DSX_CHANNEL_ACC() and
> > > ST_LSM6DSX_CHANNEL() macros with dynamic allocation and
> > > initialization of struct iio_chan_spec arrays, where the
> > > st_lsm6dsx_event structure is only used for sensors that support
> > > wakeup events; besides fixing the above bug, this serves as a
> > > preliminary step for adding support for more event types.
> > > 
> > > Signed-off-by: Francesco Lavra <flavra@...libre.com>  
> > 
> > In cases where there are only a small number of options for what the
> > channel
> > arrays should contain, my normal preference would be more data over
> > moving
> > the complexity into code.  That is have two struct iio_chan_spec arrays
> > and
> > pick between them based on availability of the interrupt.
> > 
> > I haven't checked the whole series yet, but how many channel arrays
> > would we need to support the features you are introducing here? That is
> > how many different combinations exist in the supported chips?  
> 
> In the current code there are 3 struct iio_chan_spec arrays; we would need
> one more to fix the above bug, and one more to add tap event support; so a
> total of 5 arrays (each of length 4).
> As for struct iio_event_spec, the current code has one array (of length 1),
> and to add tap event support we would need another array (of length 2).

That sounds small enough to me that I'd prefer const data that you pick between
rather than dynamic creation.

Jonathan