| Message ID | 20200826132203.236748-1-alexandru.ardelean@analog.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | iio: adc: exynos_adc: Replace indio_dev->mlock with own device lock | expand |
On Wed, Aug 26, 2020 at 04:22:03PM +0300, Alexandru Ardelean wrote: > From: Sergiu Cuciurean <sergiu.cuciurean@analog.com> > > As part of the general cleanup of indio_dev->mlock, this change replaces > it with a local lock, to protect potential concurrent access to the > completion callback during a conversion. I don't know the bigger picture (and no links here for general cleanup) but I assume it is part of wider work and that mlock is unwanted. In such case: Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> If it is part of some bigger work, please put a link to lore.kernel.org under separators ---, so everyone can get the context. Best regards, Krzysztof > > Signed-off-by: Sergiu Cuciurean <sergiu.cuciurean@analog.com> > Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> > --- > drivers/iio/adc/exynos_adc.c | 12 ++++++++---- > 1 file changed, 8 insertions(+), 4 deletions(-) >
On Thu, Aug 27, 2020 at 9:57 AM Krzysztof Kozlowski <krzk@kernel.org> wrote: > > On Wed, Aug 26, 2020 at 04:22:03PM +0300, Alexandru Ardelean wrote: > > From: Sergiu Cuciurean <sergiu.cuciurean@analog.com> > > > > As part of the general cleanup of indio_dev->mlock, this change replaces > > it with a local lock, to protect potential concurrent access to the > > completion callback during a conversion. > > I don't know the bigger picture (and no links here for general cleanup) > but I assume it is part of wider work and that mlock is unwanted. In > such case: > > Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> > > If it is part of some bigger work, please put a link to lore.kernel.org > under separators ---, so everyone can get the context. Will keep that in mind. I am not sure if there is a lore.kernel.org link that's easy to find for a discussion on this topic, maybe I can describe it here and use the link [from this later]. This was something that popped up during reviews we got from Jonathan [or others], saying "please don't use indio_dev->mlock, that is an IIO framework lock, and an IIO driver should not use it". Reasons include [and some may be repeated a bit]: - this could cause a deadlock if the IIO framework holds this lock and an IIO driver also tries to get a hold of this lock - similar to the previous point, this mlock is taken by iio_device_claim_direct_mode() and released by iio_device_release_direct_mode() ; which means that mlock aims to become more of an IIO framework lock, than a general usage lock; - this wasn't policed/reviewed intensely in the older driver [a few years ago], but has become a point in recent reviews; - if we want to develop/enhance the IIO framework, some elements like this need to be taken care of, as more drivers get added and more complexity gets added; - there is an element of fairness [obviously], where someone writing a new IIO driver, takes an older one as example, and gets hit on the review; the person feels they did a good job in mimicking the old driver; their feeling is correct; the IIO framework should provide good references and/or cleanup existing drivers; - same as the previous point, we don't want to keep telling people writing new IIO drivers [and starting out with IIO] to "not use mlock [because it was copied from an old driver]"; it's more/needless review work > > > Best regards, > Krzysztof > > > > > Signed-off-by: Sergiu Cuciurean <sergiu.cuciurean@analog.com> > > Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> > > --- > > drivers/iio/adc/exynos_adc.c | 12 ++++++++---- > > 1 file changed, 8 insertions(+), 4 deletions(-) > >
On Thu, 27 Aug 2020 11:53:44 +0300 Alexandru Ardelean <ardeleanalex@gmail.com> wrote: > On Thu, Aug 27, 2020 at 9:57 AM Krzysztof Kozlowski <krzk@kernel.org> wrote: > > > > On Wed, Aug 26, 2020 at 04:22:03PM +0300, Alexandru Ardelean wrote: > > > From: Sergiu Cuciurean <sergiu.cuciurean@analog.com> > > > > > > As part of the general cleanup of indio_dev->mlock, this change replaces > > > it with a local lock, to protect potential concurrent access to the > > > completion callback during a conversion. > > > > I don't know the bigger picture (and no links here for general cleanup) > > but I assume it is part of wider work and that mlock is unwanted. In > > such case: > > > > Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> > > > > If it is part of some bigger work, please put a link to lore.kernel.org > > under separators ---, so everyone can get the context. > > Will keep that in mind. > I am not sure if there is a lore.kernel.org link that's easy to find > for a discussion on this topic, maybe I can describe it here and use > the link [from this later]. > > This was something that popped up during reviews we got from Jonathan > [or others], saying "please don't use indio_dev->mlock, that is an IIO > framework lock, and an IIO driver should not use it". Shortest one is the docs for that lock say don't use it directly in a driver :) https://elixir.bootlin.com/linux/latest/source/include/linux/iio/iio.h#L495 > Reasons include [and some may be repeated a bit]: > - this could cause a deadlock if the IIO framework holds this lock and > an IIO driver also tries to get a hold of this lock > - similar to the previous point, this mlock is taken by > iio_device_claim_direct_mode() and released by > iio_device_release_direct_mode() ; which means that mlock aims to > become more of an IIO framework lock, than a general usage lock; > - this wasn't policed/reviewed intensely in the older driver [a few > years ago], but has become a point in recent reviews; > - if we want to develop/enhance the IIO framework, some elements like > this need to be taken care of, as more drivers get added and more > complexity gets added; One side note here is we want to make all this [INTERN] state in struct iio_dev opaque to drivers. It'll take a while as the boundary gets crossed in various drivers. > - there is an element of fairness [obviously], where someone writing a > new IIO driver, takes an older one as example, and gets hit on the > review; the person feels they did a good job in mimicking the old > driver; their feeling is correct; the IIO framework should provide > good references and/or cleanup existing drivers; > - same as the previous point, we don't want to keep telling people > writing new IIO drivers [and starting out with IIO] to "not use mlock > [because it was copied from an old driver]"; it's more/needless review > work Good explanation. Thanks, Jonathan > > > > > > > > Best regards, > > Krzysztof > > > > > > > > Signed-off-by: Sergiu Cuciurean <sergiu.cuciurean@analog.com> > > > Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> > > > --- > > > drivers/iio/adc/exynos_adc.c | 12 ++++++++---- > > > 1 file changed, 8 insertions(+), 4 deletions(-) > > >
On Wed, 26 Aug 2020 16:22:03 +0300 Alexandru Ardelean <alexandru.ardelean@analog.com> wrote: > From: Sergiu Cuciurean <sergiu.cuciurean@analog.com> > > As part of the general cleanup of indio_dev->mlock, this change replaces > it with a local lock, to protect potential concurrent access to the > completion callback during a conversion. > > Signed-off-by: Sergiu Cuciurean <sergiu.cuciurean@analog.com> > Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Same comment as the other one about needing lock scope to be documented. Otherwise looks good. I thought we only had complicated uses of this left, but clearly not :) Jonathan > --- > drivers/iio/adc/exynos_adc.c | 12 ++++++++---- > 1 file changed, 8 insertions(+), 4 deletions(-) > > diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c > index 7d23b6c33284..6a49f8dfab22 100644 > --- a/drivers/iio/adc/exynos_adc.c > +++ b/drivers/iio/adc/exynos_adc.c > @@ -132,6 +132,8 @@ struct exynos_adc { > > struct completion completion; > > + struct mutex lock; > + > u32 value; > unsigned int version; > > @@ -542,7 +544,7 @@ static int exynos_read_raw(struct iio_dev *indio_dev, > return -EINVAL; > } > > - mutex_lock(&indio_dev->mlock); > + mutex_lock(&info->lock); > reinit_completion(&info->completion); > > /* Select the channel to be used and Trigger conversion */ > @@ -562,7 +564,7 @@ static int exynos_read_raw(struct iio_dev *indio_dev, > ret = IIO_VAL_INT; > } > > - mutex_unlock(&indio_dev->mlock); > + mutex_unlock(&info->lock); > > return ret; > } > @@ -573,7 +575,7 @@ static int exynos_read_s3c64xx_ts(struct iio_dev *indio_dev, int *x, int *y) > unsigned long timeout; > int ret; > > - mutex_lock(&indio_dev->mlock); > + mutex_lock(&info->lock); > info->read_ts = true; > > reinit_completion(&info->completion); > @@ -598,7 +600,7 @@ static int exynos_read_s3c64xx_ts(struct iio_dev *indio_dev, int *x, int *y) > } > > info->read_ts = false; > - mutex_unlock(&indio_dev->mlock); > + mutex_unlock(&info->lock); > > return ret; > } > @@ -872,6 +874,8 @@ static int exynos_adc_probe(struct platform_device *pdev) > indio_dev->channels = exynos_adc_iio_channels; > indio_dev->num_channels = info->data->num_channels; > > + mutex_init(&info->lock); > + > ret = request_irq(info->irq, exynos_adc_isr, > 0, dev_name(&pdev->dev), info); > if (ret < 0) {
diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c index 7d23b6c33284..6a49f8dfab22 100644 --- a/drivers/iio/adc/exynos_adc.c +++ b/drivers/iio/adc/exynos_adc.c @@ -132,6 +132,8 @@ struct exynos_adc { struct completion completion; + struct mutex lock; + u32 value; unsigned int version; @@ -542,7 +544,7 @@ static int exynos_read_raw(struct iio_dev *indio_dev, return -EINVAL; } - mutex_lock(&indio_dev->mlock); + mutex_lock(&info->lock); reinit_completion(&info->completion); /* Select the channel to be used and Trigger conversion */ @@ -562,7 +564,7 @@ static int exynos_read_raw(struct iio_dev *indio_dev, ret = IIO_VAL_INT; } - mutex_unlock(&indio_dev->mlock); + mutex_unlock(&info->lock); return ret; } @@ -573,7 +575,7 @@ static int exynos_read_s3c64xx_ts(struct iio_dev *indio_dev, int *x, int *y) unsigned long timeout; int ret; - mutex_lock(&indio_dev->mlock); + mutex_lock(&info->lock); info->read_ts = true; reinit_completion(&info->completion); @@ -598,7 +600,7 @@ static int exynos_read_s3c64xx_ts(struct iio_dev *indio_dev, int *x, int *y) } info->read_ts = false; - mutex_unlock(&indio_dev->mlock); + mutex_unlock(&info->lock); return ret; } @@ -872,6 +874,8 @@ static int exynos_adc_probe(struct platform_device *pdev) indio_dev->channels = exynos_adc_iio_channels; indio_dev->num_channels = info->data->num_channels; + mutex_init(&info->lock); + ret = request_irq(info->irq, exynos_adc_isr, 0, dev_name(&pdev->dev), info); if (ret < 0) {