linux-iio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Himangi Saraogi <himangi774@gmail.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-iio@vger.kernel.org, devel@driverdev.osuosl.org,
	linux-kernel@vger.kernel.org
Cc: Julia Lawall <julia.lawall@lip6.fr>
Subject: Re: questions regarding drivers/staging/iio/accel/sca3000_core.c
Date: Sun, 27 Jul 2014 17:24:27 +0100	[thread overview]
Message-ID: <53D527BB.30309@kernel.org> (raw)
In-Reply-To: <CAB78YHyh88+j-knC1HZQinnLU=9wbVPXrYRF81LeOtrV1oGmZA@mail.gmail.com>

On 21/07/14 09:24, Himangi Saraogi wrote:
> Hi,
>
> I was looking at the possibility of using a managed interface for
> iio_device_register in sca3000_probe. But this will lead to the
> iio_device_unregister function being called after
> sca3000_unconfigure_ring in the remove function. I have a few
> queries:
>
> 1. Is it safe to move the unregister function over the
> sca3000_unconfigure_ring?
No, in fact it should be before various other things
(though it isn't currently).  The device unregister
removes the userspace interfaces.  Hence it should always
be called before anything else happens in a remove function.
>
> 2. Is it correct that on failure the probe function does not call
> sca3000_unconfigure_ring?
Nope. That's a bug.  Actually the whole probe function ordering is
suspicious. The device register should probably be a lot later
(i.e. last). There might be some esoteric reason that isn't the case
but I honestly can't remember.  Whilst I have one of these parts
the wire bodge needs repairing and I haven't fired the board it plugs
into up for a good while.  If it wasn't such and interesting part I'd
be tempted to suggest dropping the driver entirely (and find out if
anyone else actually has one in the process!)
>
> 3. If it is fine moving unregister after sca3000_unconfigure_ring, I
> propose to add a devm counterpart of iio_buffer_unregister. Is it a
> good idea?
I'm not sure there enough users to bother and some of those should
probably use the triggered_buffer helper functions.
>
> Thanks, Himangi

      reply	other threads:[~2014-07-27 16:22 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-21  8:24 questions regarding drivers/staging/iio/accel/sca3000_core.c Himangi Saraogi
2014-07-27 16:24 ` Jonathan Cameron [this message]

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=53D527BB.30309@kernel.org \
    --to=jic23@kernel.org \
    --cc=devel@driverdev.osuosl.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=himangi774@gmail.com \
    --cc=julia.lawall@lip6.fr \
    --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;
as well as URLs for NNTP newsgroup(s).