public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Vincent Whitchurch <vincent.whitchurch@axis.com>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Jonathan Cameron <jic23@kernel.org>, kernel <kernel@axis.com>,
	Lars-Peter Clausen <lars@metafoo.de>,
	Axel Jonsson <Axel.Jonsson@axis.com>,
	linux-iio <linux-iio@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] iio: adc: mcp320x: use device managed functions
Date: Fri, 26 Aug 2022 13:38:39 +0200	[thread overview]
Message-ID: <Ywiwv8TZ5oomTuHK@axis.com> (raw)
In-Reply-To: <CAHp75Vf4C0hauoT7F26zS7815Cps=W3o1_HHmWKVbrUi90FcrQ@mail.gmail.com>

On Thu, Aug 25, 2022 at 10:01:58PM +0200, Andy Shevchenko wrote:
> On Wed, Aug 24, 2022 at 1:46 PM Vincent Whitchurch
> <vincent.whitchurch@axis.com> 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()).

  reply	other threads:[~2022-08-26 11:38 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-24 10:40 [PATCH 0/2] iio: adc: mcp320x: Add triggered buffer support Vincent Whitchurch
2022-08-24 10:40 ` [PATCH 1/2] iio: adc: mcp320x: use device managed functions Vincent Whitchurch
2022-08-25 20:01   ` Andy Shevchenko
2022-08-26 11:38     ` Vincent Whitchurch [this message]
     [not found]       ` <CAHp75VffYzNTfrki4+o8JJayUGo1n91bP0hSzB-fR=RfcFq-fw@mail.gmail.com>
2022-08-28 17:06         ` Jonathan Cameron
2022-08-29  8:16           ` Andy Shevchenko
2022-08-24 10:40 ` [PATCH 2/2] iio: adc: mcp320x: add triggered buffer support Vincent Whitchurch
2022-08-25 20:06   ` Andy Shevchenko
2022-08-28 17:15     ` Jonathan Cameron
2022-08-28 17:24   ` Jonathan Cameron
2022-08-31  7:47     ` Vincent Whitchurch
2022-09-04 16:29       ` Jonathan Cameron

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Ywiwv8TZ5oomTuHK@axis.com \
    --to=vincent.whitchurch@axis.com \
    --cc=Axel.Jonsson@axis.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=jic23@kernel.org \
    --cc=kernel@axis.com \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox