| Message ID | 20220606111316.19265-1-ddrokosov@sberdevices.ru (mailing list archive) |
|---|---|
| State | Accepted |
| Headers | show |
| Series | [v2] iio: trigger: warn about non-registered iio trigger getting attempt | expand |
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() ?
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.
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;
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(+)