RE: [PATCH 03/15] iio: adc: axp288_adc: do not use internal iio_dev lock

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> -----Original Message-----
> From: Andy Shevchenko <andy.shevchenko@xxxxxxxxx>
> Sent: Tuesday, September 20, 2022 3:13 PM
> To: Sa, Nuno <Nuno.Sa@xxxxxxxxxx>
> Cc: linux-arm-kernel@xxxxxxxxxxxxxxxxxxx; linux-rockchip@xxxxxxxxxxxxxxxxxxx;
> linux-amlogic@xxxxxxxxxxxxxxxxxxx; linux-imx@xxxxxxx; linux-
> iio@xxxxxxxxxxxxxxx; Chunyan Zhang <zhang.lyra@xxxxxxxxx>; Hennerich,
> Michael <Michael.Hennerich@xxxxxxxxxx>; Martin Blumenstingl
> <martin.blumenstingl@xxxxxxxxxxxxxx>; Sascha Hauer
> <s.hauer@xxxxxxxxxxxxxx>; Cixi Geng <cixi.geng1@xxxxxxxxxx>; Kevin
> Hilman <khilman@xxxxxxxxxxxx>; Vladimir Zapolskiy <vz@xxxxxxxxx>;
> Pengutronix Kernel Team <kernel@xxxxxxxxxxxxxx>; Alexandru Ardelean
> <aardelean@xxxxxxxxxxx>; Fabio Estevam <festevam@xxxxxxxxx>; Andriy
> Tryshnivskyy <andriy.tryshnivskyy@xxxxxxxxxxxxxxx>; Haibo Chen
> <haibo.chen@xxxxxxx>; Shawn Guo <shawnguo@xxxxxxxxxx>; Hans de
> Goede <hdegoede@xxxxxxxxxx>; Miquel Raynal
> <miquel.raynal@xxxxxxxxxxx>; Jerome Brunet <jbrunet@xxxxxxxxxxxx>;
> Heiko Stuebner <heiko@xxxxxxxxx>; Florian Boor
> <florian.boor@xxxxxxxxxxxxxxxxx>; Regus, Ciprian
> <Ciprian.Regus@xxxxxxxxxx>; Lars-Peter Clausen <lars@xxxxxxxxxx>;
> Jonathan Cameron <jic23@xxxxxxxxxx>; Neil Armstrong
> <narmstrong@xxxxxxxxxxxx>; Baolin Wang
> <baolin.wang@xxxxxxxxxxxxxxxxx>; Jyoti Bhayana <jbhayana@xxxxxxxxxx>;
> Chen-Yu Tsai <wens@xxxxxxxx>; Orson Zhai <orsonzhai@xxxxxxxxx>
> Subject: Re: [PATCH 03/15] iio: adc: axp288_adc: do not use internal iio_dev
> lock
> 
> [External]
> 
> On Tue, Sep 20, 2022 at 2:28 PM Nuno Sá <nuno.sa@xxxxxxxxxx> wrote:
> >
> > The iio_device lock is only meant for internal use. Hence define a
> > device local lock to protect against concurrent accesses.
> 
> ...
> 
> >         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.

- Nuno Sá




[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Input]     [Linux Kernel]     [Linux SCSI]     [X.org]

  Powered by Linux