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

Message-ID: <20251102111648.73422267@jic23-huawei>
Date: Sun, 2 Nov 2025 11:16:48 +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 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?

Jonathan