From: Jonathan Cameron <jic23@kernel.org>
To: Andy Shevchenko <andriy.shevchenko@intel.com>
Cc: Jonathan Cameron <jonathan.cameron@huawei.com>,
Siratul Islam <email@sirat.me>,
linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
dlechner@baylibre.com, nuno.sa@analog.com, andy@kernel.org,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v7 2/2] iio: proximity: add driver for ST VL53L1X ToF sensor
Date: Sun, 12 Apr 2026 16:40:02 +0100 [thread overview]
Message-ID: <20260412164002.55191c16@jic23-huawei> (raw)
In-Reply-To: <acT48bou7k15NTQD@ashevche-desk.local>
On Thu, 26 Mar 2026 11:14:25 +0200
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> On Wed, Mar 25, 2026 at 02:47:19PM +0000, Jonathan Cameron wrote:
> > On Wed, 25 Mar 2026 12:32:23 +0600
> > Siratul Islam <email@sirat.me> wrote:
>
> ...
>
> > > + trig = devm_iio_trigger_alloc(dev, "%s-dev%d", indio_dev->name,
> > > + iio_device_id(indio_dev));
> > > + if (!trig)
> > > + return -ENOMEM;
> > > +
> > > + trig->ops = &vl53l1x_trigger_ops;
> > > + iio_trigger_set_drvdata(trig, indio_dev);
> > > + ret = devm_iio_trigger_register(dev, trig);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + indio_dev->trig = iio_trigger_get(trig);
> >
> > So Sashiko had a comment on this that has me thinking. Don't bother fixing it
> > in this driver as it true it's a common bug (and leaks a trigger structure).
> > I'll look into it.
>
> This probably can be worked around by introducing a flag devm_allocated and set
> it in devm_iio_trigger_alloc(). If set, the release might automatically put the
> trigger at the error cases.
(see below as your second point is key to what I'm saying here!)
Approximately what I had in mind, but not there - rather in a new
devm_iio_trigger_get() which would set a flag somewhere to say clean up needed.
The fiddly bit is when to clear it. I think logically needs to be both:
1) When the trigger is changed as we put the trigger there anyway
2) (maybe implicitly) if the flag is still set on a devm callback registered
by devm_iio_trigger_get().
That devm callback is to ensure correct ordered tear down. I really dislike
reasoning what happens if we do that stuff out of order.
> BUT, do all drivers that allocate trigger actually
> bump its reference count?
Not all drivers set the default. I actively discouraged this for a long time
due to it putting a strong preference for internal triggers when the
right choice is very usecase dependent.
The ones that set the default 'should' all use iio_trigger_get().
We had a whole bunch of fixes for this a long time back.
Anyhow, was complex enough and a common enough problem I wasn't
going to ask this contributor to deal with it. I should have some time
in the next week or two to put together all the test cases needed to
make sure a solution works for this.
Jonathan
>
> > > + ret = vl53l1x_configure_irq(dev, client->irq, indio_dev);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + ret = devm_iio_triggered_buffer_setup(dev, indio_dev, NULL,
> > > + &vl53l1x_trigger_handler,
> > > + NULL);
> > > + if (ret)
> > > + return ret;
>
next prev parent reply other threads:[~2026-04-12 15:40 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-25 6:32 [PATCH v7 0/2] iio: proximity: add driver for ST VL53L1X ToF sensor Siratul Islam
2026-03-25 6:32 ` [PATCH v7 1/2] dt-bindings: iio: proximity: add " Siratul Islam
2026-03-25 8:05 ` Krzysztof Kozlowski
2026-03-25 8:48 ` Sirat
2026-03-25 8:57 ` Krzysztof Kozlowski
2026-03-25 9:18 ` Sirat
2026-03-25 13:38 ` Jonathan Cameron
2026-03-25 13:44 ` Krzysztof Kozlowski
2026-03-25 14:06 ` Jonathan Cameron
2026-03-25 14:38 ` Sirat
2026-03-25 15:01 ` Jonathan Cameron
2026-03-25 6:32 ` [PATCH v7 2/2] iio: proximity: add driver for " Siratul Islam
2026-03-25 14:47 ` Jonathan Cameron
2026-03-25 16:33 ` Sirat
2026-03-25 19:47 ` Jonathan Cameron
2026-03-26 9:14 ` Andy Shevchenko
2026-04-12 15:40 ` Jonathan Cameron [this message]
2026-03-25 7:55 ` [PATCH v7 0/2] " Krzysztof Kozlowski
2026-03-25 8:23 ` Sirat
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260412164002.55191c16@jic23-huawei \
--to=jic23@kernel.org \
--cc=andriy.shevchenko@intel.com \
--cc=andy@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dlechner@baylibre.com \
--cc=email@sirat.me \
--cc=jonathan.cameron@huawei.com \
--cc=krzk+dt@kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nuno.sa@analog.com \
--cc=robh@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox