On Tue, Sep 20, 2022 at 4:37 PM Andy Shevchenko <andy.shevchenko@xxxxxxxxx> wrote: > On Tue, Sep 20, 2022 at 4:18 PM Sa, Nuno <Nuno.Sa@xxxxxxxxxx> wrote: > > > On Tue, Sep 20, 2022 at 2:28 PM Nuno Sá <nuno.sa@xxxxxxxxxx> wrote: ... > > > > info = iio_priv(indio_dev); > > > > + mutex_init(&info->lock); > > > > info->irq = platform_get_irq(pdev, 0); > > > > if (info->irq < 0) > > > > return info->irq; > > > > > > Consider initializing it as late as possible, like after IRQ retrieval > > > in this context (maybe even deeper, but no context available). Ditto > > > for the rest of the series. > > > > Any special reason for it (maybe related to lockdep :wondering: ) ? Just > > curious as I never noticed such a pattern when initializing mutexes. > > Yes. Micro-optimization based on the rule "don't create a resource in > case of known error". > > OTOH, you have to be sure that the mutex (and generally speaking a > locking) should be initialized early enough. Note that "micro" in the above can be multiplied by 'k', where 'k' is the amount of deferred probes (probably not the case here, but again, "generally speaking"). -- With Best Regards, Andy Shevchenko
