linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v2] iio: trigger: warn about non-registered iio trigger getting attempt
@ 2022-06-06 11:12 Dmitry Rokosov
  2022-06-06 12:42 ` Andy Shevchenko
  0 siblings, 1 reply; 3+ messages in thread
From: Dmitry Rokosov @ 2022-06-06 11:12 UTC (permalink / raw)
  To: robh+dt, jic23, lars, andy.shevchenko, noname.nuno
  Cc: linux-iio, kernel, linux-kernel, Dmitry Rokosov

As a part of patch series about wrong trigger register() and get()
calls order in the some IIO drivers trigger initialization path:

https://lore.kernel.org/all/20220524181150.9240-1-ddrokosov@sberdevices.ru/

runtime WARN() is added to alarm IIO driver authors who make such
a mistake.

When IIO driver allocates a new IIO trigger, it should register it before
calling the get() operation. In other words, each IIO driver must abide by
IIO trigger alloc()/register()/get() calls order.

Signed-off-by: Dmitry Rokosov <ddrokosov@sberdevices.ru>
---
 drivers/iio/industrialio-trigger.c | 2 ++
 include/linux/iio/trigger.h        | 5 +++++
 2 files changed, 7 insertions(+)

diff --git a/drivers/iio/industrialio-trigger.c b/drivers/iio/industrialio-trigger.c
index f504ed351b3e..d6277e72d515 100644
--- a/drivers/iio/industrialio-trigger.c
+++ b/drivers/iio/industrialio-trigger.c
@@ -581,6 +581,8 @@ struct iio_trigger *viio_trigger_alloc(struct device *parent,
 	if (trig->name == NULL)
 		goto free_descs;
 
+	INIT_LIST_HEAD(&trig->list);
+
 	trig->subirq_chip.name = trig->name;
 	trig->subirq_chip.irq_mask = &iio_trig_subirqmask;
 	trig->subirq_chip.irq_unmask = &iio_trig_subirqunmask;
diff --git a/include/linux/iio/trigger.h b/include/linux/iio/trigger.h
index 4c69b144677b..2d71cb331f1c 100644
--- a/include/linux/iio/trigger.h
+++ b/include/linux/iio/trigger.h
@@ -93,6 +93,11 @@ static inline void iio_trigger_put(struct iio_trigger *trig)
 static inline struct iio_trigger *iio_trigger_get(struct iio_trigger *trig)
 {
 	get_device(&trig->dev);
+
+	WARN(list_empty(&trig->list),
+	     "Getting non-registered iio trigger %s is prohibited\n",
+	     trig->name);
+
 	__module_get(trig->owner);
 
 	return trig;
-- 
2.36.0

^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [PATCH v2] iio: trigger: warn about non-registered iio trigger getting attempt
  2022-06-06 11:12 [PATCH v2] iio: trigger: warn about non-registered iio trigger getting attempt Dmitry Rokosov
@ 2022-06-06 12:42 ` Andy Shevchenko
  2022-06-07 16:54   ` Dmitry Rokosov
  0 siblings, 1 reply; 3+ messages in thread
From: Andy Shevchenko @ 2022-06-06 12:42 UTC (permalink / raw)
  To: Dmitry Rokosov
  Cc: robh+dt, jic23, lars, noname.nuno, linux-iio, kernel, linux-kernel

On Mon, Jun 6, 2022 at 1:23 PM Dmitry Rokosov <DDRokosov@sberdevices.ru> wrote:
>
> As a part of patch series about wrong trigger register() and get()
> calls order in the some IIO drivers trigger initialization path:
>
> https://lore.kernel.org/all/20220524181150.9240-1-ddrokosov@sberdevices.ru/
>
> runtime WARN() is added to alarm IIO driver authors who make such
> a mistake.
>
> When IIO driver allocates a new IIO trigger, it should register it before

an IIO

> calling the get() operation. In other words, each IIO driver must abide by
> IIO trigger alloc()/register()/get() calls order.

I believe triggers usually acquired at ->probe() time, means that in
case if the following code (however, I believe it will be quite rare)
goes into deferred probe cycle the WARN will be repeated. Perhaps
WARN_ONCE() ?

-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH v2] iio: trigger: warn about non-registered iio trigger getting attempt
  2022-06-06 12:42 ` Andy Shevchenko
@ 2022-06-07 16:54   ` Dmitry Rokosov
  0 siblings, 0 replies; 3+ messages in thread
From: Dmitry Rokosov @ 2022-06-07 16:54 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: robh+dt, jic23, lars, noname.nuno, linux-iio, kernel, linux-kernel

Hello Andy,

Thank you for the quick reply.

On Mon, Jun 06, 2022 at 02:42:18PM +0200, Andy Shevchenko wrote:
> On Mon, Jun 6, 2022 at 1:23 PM Dmitry Rokosov <DDRokosov@sberdevices.ru> wrote:
> >
> > As a part of patch series about wrong trigger register() and get()
> > calls order in the some IIO drivers trigger initialization path:
> >
> > https://lore.kernel.org/all/20220524181150.9240-1-ddrokosov@sberdevices.ru/
> >
> > runtime WARN() is added to alarm IIO driver authors who make such
> > a mistake.
> >
> > When IIO driver allocates a new IIO trigger, it should register it before
> 
> an IIO
> 
> > calling the get() operation. In other words, each IIO driver must abide by
> > IIO trigger alloc()/register()/get() calls order.
> 
> I believe triggers usually acquired at ->probe() time, means that in
> case if the following code (however, I believe it will be quite rare)
> goes into deferred probe cycle the WARN will be repeated. Perhaps
> WARN_ONCE() ?

You are totally right. I've tested deferred probing using -EPROBE_DEFER
injection to probe() code path and WARN() was called each time. I'll fix
it in the v3 as you suggested.

-- 
Thank you,
Dmitry

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2022-06-07 16:54 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-06-06 11:12 [PATCH v2] iio: trigger: warn about non-registered iio trigger getting attempt Dmitry Rokosov
2022-06-06 12:42 ` Andy Shevchenko
2022-06-07 16:54   ` Dmitry Rokosov

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).