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

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

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