public inbox for linux-iio@vger.kernel.org
 help / color / mirror / Atom feed
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;  
> 


  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