Re: [PATCH] iio: st_sensors: fix trigger allocation

[Jonathan Cameron <jic23@kernel.org>]

On Sun, 01 Mar 2026 10:50:10 +0000
Aleksandrs Vinarskis <alex@vinarskis.com> wrote:

> On Saturday, February 28th, 2026 at 20:22, David Lechner <dlechner@baylibre.com> wrote:
> 
> > On 2/28/26 11:11 AM, Aleksandrs Vinarskis wrote:  
> > > Current hardcoded name prevents adding multiple st-sensors devices
> > > on the same platform. Fix by aligning trigger name with other drivers.
> > >
> > > Signed-off-by: Aleksandrs Vinarskis <alex@vinarskis.com>
> > > ---
> > > Some platforms such as Dell XPS 9345 contains multiple accelerometers.
> > > Fix st_sensors that currently only allows one device at the time.
> > > ---
> > >  drivers/iio/common/st_sensors/st_sensors_trigger.c | 5 +++--
> > >  1 file changed, 3 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/iio/common/st_sensors/st_sensors_trigger.c b/drivers/iio/common/st_sensors/st_sensors_trigger.c
> > > index 8a8ab688d7980f6dd43c660f90a0eba32c38388b..3b5615d1b6dd66ee0af6ccc83eb2fbd7b2c64d29 100644
> > > --- a/drivers/iio/common/st_sensors/st_sensors_trigger.c
> > > +++ b/drivers/iio/common/st_sensors/st_sensors_trigger.c
> > > @@ -124,8 +124,9 @@ int st_sensors_allocate_trigger(struct iio_dev *indio_dev,
> > >  	unsigned long irq_trig;
> > >  	int err;
> > >
> > > -	sdata->trig = devm_iio_trigger_alloc(parent, "%s-trigger",
> > > -					     indio_dev->name);
> > > +	sdata->trig = devm_iio_trigger_alloc(parent, "%s-dev%d",
> > > +					     indio_dev->name,
> > > +					     iio_device_id(indio_dev));  
> > 
> > Is this something that could potentially break userspace? Or are all of these
> > just "always there" triggers that userspace doesn't have to touch?  
> 
> I don't see why it would. This simply makes the name of the registered
> trigger globally unique, the same way like other drivers already do.
> Userspace does care about these but it relies on capabilities as per
> my understanding to figure what sensor it is. I have tested it with
> `monitor-sensors`, which relies on `iio-sensor-proxy`: in both cases
> accelerator device was detected.

Most userspace hopefully relies on the relationship between the trigger
and the device (basically that they have the same parent) rather than the
explicit name, but it is always possible someone does have a script using
this name.  I don't think these drivers are setting a default (which is
reasonable as IIRC they have always supported other triggers and people
have a habit of not wiring the interrupts up).

So David's right that this could cause a user visible regression. 
We might get away with it though.

Today, iio_trigger_acquire_by_name() just matches the first one with a
given string.   This isn't a fast path so we could be a little cleverer
and add a heuristic that first tries to find a trigger with that name
and a common parent device.  If that fails, it just falls back to the
current approach?  That way it would do the right thing in cases like
the one seen here, but we'd not be able to have one ST sensor trigger
off a specific other on - not sure that's a big loss however as it
is fairly unusual to do that for similar sensor types.

What do people think?  Alex, would that work for your case?

Jonathan



> 
> Alex
> 
> >   
> > >  	if (sdata->trig == NULL) {
> > >  		dev_err(parent, "failed to allocate iio trigger.\n");
> > >  		return -ENOMEM;
> > >
> > > ---
> > > base-commit: 3fa5e5702a82d259897bd7e209469bc06368bf31
> > > change-id: 20260228-st-iio-trigger-8ee1f219b566
> > >
> > > Best regards,  
> > 
> >