This series adds triggered buffer support to the mcp320x ADC driver. Tested on
MCP3008.
Cc: [email protected]
Cc: [email protected]
Axel Jonsson (1):
iio: adc: mcp320x: add triggered buffer support
Vincent Whitchurch (1):
iio: adc: mcp320x: use device managed functions
drivers/iio/adc/Kconfig | 2 +
drivers/iio/adc/mcp320x.c | 158 +++++++++++++++++++++++++-------------
2 files changed, 108 insertions(+), 52 deletions(-)
--
2.34.1
Use devm_* functions in probe to remove some code and to make it easier
to add further calls to the probe function.
Signed-off-by: Vincent Whitchurch <[email protected]>
---
drivers/iio/adc/mcp320x.c | 30 ++++++++++--------------------
1 file changed, 10 insertions(+), 20 deletions(-)
diff --git a/drivers/iio/adc/mcp320x.c b/drivers/iio/adc/mcp320x.c
index b4c69acb33e3..28398f34628a 100644
--- a/drivers/iio/adc/mcp320x.c
+++ b/drivers/iio/adc/mcp320x.c
@@ -371,6 +371,11 @@ static const struct mcp320x_chip_info mcp320x_chip_infos[] = {
},
};
+static void mcp320x_reg_disable(void *reg)
+{
+ regulator_disable(reg);
+}
+
static int mcp320x_probe(struct spi_device *spi)
{
struct iio_dev *indio_dev;
@@ -445,27 +450,13 @@ static int mcp320x_probe(struct spi_device *spi)
if (ret < 0)
return ret;
- mutex_init(&adc->lock);
-
- ret = iio_device_register(indio_dev);
- if (ret < 0)
- goto reg_disable;
-
- return 0;
-
-reg_disable:
- regulator_disable(adc->reg);
-
- return ret;
-}
+ ret = devm_add_action_or_reset(&spi->dev, mcp320x_reg_disable, adc->reg);
+ if (ret)
+ return ret;
-static void mcp320x_remove(struct spi_device *spi)
-{
- struct iio_dev *indio_dev = spi_get_drvdata(spi);
- struct mcp320x *adc = iio_priv(indio_dev);
+ mutex_init(&adc->lock);
- iio_device_unregister(indio_dev);
- regulator_disable(adc->reg);
+ return devm_iio_device_register(&spi->dev, indio_dev);
}
static const struct of_device_id mcp320x_dt_ids[] = {
@@ -520,7 +511,6 @@ static struct spi_driver mcp320x_driver = {
.of_match_table = mcp320x_dt_ids,
},
.probe = mcp320x_probe,
- .remove = mcp320x_remove,
.id_table = mcp320x_id,
};
module_spi_driver(mcp320x_driver);
--
2.34.1
On Wed, Aug 24, 2022 at 1:46 PM Vincent Whitchurch
<[email protected]> wrote:
>
> Use devm_* functions in probe to remove some code and to make it easier
> to add further calls to the probe function.
...
> + mutex_init(&adc->lock);
> + return devm_iio_device_register(&spi->dev, indio_dev);
Do you still need to destroy the mutex? If so, you may not call devm_
variant of iio_device_register() or you have to wrap mutex_destroy()
accordingly.
--
With Best Regards,
Andy Shevchenko
On Thu, Aug 25, 2022 at 10:01:58PM +0200, Andy Shevchenko wrote:
> On Wed, Aug 24, 2022 at 1:46 PM Vincent Whitchurch
> <[email protected]> wrote:
> >
> > Use devm_* functions in probe to remove some code and to make it easier
> > to add further calls to the probe function.
>
> ...
>
> > + mutex_init(&adc->lock);
>
> > + return devm_iio_device_register(&spi->dev, indio_dev);
>
> Do you still need to destroy the mutex? If so, you may not call devm_
> variant of iio_device_register() or you have to wrap mutex_destroy()
> accordingly.
mutex_destroy() is only used to ensure that mutex debugging catches
further use of the mutex. Isn't it rather overkill to add specific
cleanup to do only that, especially in this case when it's anyway going
to get freed immediately afterwards? The vast majority of IIO drivers
don't call mutex_destroy() (256 calls to mutex_init() in HEAD vs 12 to
mutex_destroy()).
On Fri, 26 Aug 2022 14:57:44 +0300
Andy Shevchenko <[email protected]> wrote:
> On Friday, August 26, 2022, Vincent Whitchurch <[email protected]>
> wrote:
>
> > On Thu, Aug 25, 2022 at 10:01:58PM +0200, Andy Shevchenko wrote:
> > > On Wed, Aug 24, 2022 at 1:46 PM Vincent Whitchurch
> > > <[email protected]> wrote:
> > > >
> > > > Use devm_* functions in probe to remove some code and to make it easier
> > > > to add further calls to the probe function.
> > >
> > > ...
> > >
> > > > + mutex_init(&adc->lock);
> > >
> > > > + return devm_iio_device_register(&spi->dev, indio_dev);
> > >
> > > Do you still need to destroy the mutex? If so, you may not call devm_
> > > variant of iio_device_register() or you have to wrap mutex_destroy()
> > > accordingly.
> >
> > mutex_destroy() is only used to ensure that mutex debugging catches
> > further use of the mutex. Isn't it rather overkill to add specific
> > cleanup to do only that, especially in this case when it's anyway going
> > to get freed immediately afterwards? The vast majority of IIO drivers
> > don't call mutex_destroy() (256 calls to mutex_init() in HEAD vs 12 to
> > mutex_destroy()).
> >
>
>
> So 256 - 12 = 244 drivers are not pedantic.
I long ago decided mutex_destroy() in remove() paths just isn't worth the
effort. It makes absolute sense in more complex flows, but in cases
like this it's just annoying and makes the cleanup harder.
Hence I'd prefer we just ignore it's existence in cases like this.
If someone finds me a bug that it would have caught then I might
change my mind ;)
If anyone wants a giggle via adding a devm_mutex_init() call it
might be interesting to see the responses. Would be unusual in
that it would just be mutex_init() in unless the mutex debugging
is turned on...
Jonathan
On Sun, Aug 28, 2022 at 8:40 PM Jonathan Cameron <[email protected]> wrote:
> On Fri, 26 Aug 2022 14:57:44 +0300
> Andy Shevchenko <[email protected]> wrote:
> > On Friday, August 26, 2022, Vincent Whitchurch <[email protected]>
> > wrote:
> > > On Thu, Aug 25, 2022 at 10:01:58PM +0200, Andy Shevchenko wrote:
> > > > On Wed, Aug 24, 2022 at 1:46 PM Vincent Whitchurch
> > > > <[email protected]> wrote:
> > > > >
> > > > > Use devm_* functions in probe to remove some code and to make it easier
> > > > > to add further calls to the probe function.
> > > >
> > > > ...
> > > >
> > > > > + mutex_init(&adc->lock);
> > > >
> > > > > + return devm_iio_device_register(&spi->dev, indio_dev);
> > > >
> > > > Do you still need to destroy the mutex? If so, you may not call devm_
> > > > variant of iio_device_register() or you have to wrap mutex_destroy()
> > > > accordingly.
> > >
> > > mutex_destroy() is only used to ensure that mutex debugging catches
> > > further use of the mutex. Isn't it rather overkill to add specific
> > > cleanup to do only that, especially in this case when it's anyway going
> > > to get freed immediately afterwards? The vast majority of IIO drivers
> > > don't call mutex_destroy() (256 calls to mutex_init() in HEAD vs 12 to
> > > mutex_destroy()).
> >
> > So 256 - 12 = 244 drivers are not pedantic.
>
> I long ago decided mutex_destroy() in remove() paths just isn't worth the
> effort. It makes absolute sense in more complex flows, but in cases
> like this it's just annoying and makes the cleanup harder.
>
> Hence I'd prefer we just ignore it's existence in cases like this.
>
> If someone finds me a bug that it would have caught then I might
> change my mind ;)
>
> If anyone wants a giggle via adding a devm_mutex_init() call it
> might be interesting to see the responses. Would be unusual in
> that it would just be mutex_init() in unless the mutex debugging
> is turned on...
Agree on these points. Sometimes too much pedanticy is too much.
--
With Best Regards,
Andy Shevchenko