linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Daniel Baluta <daniel.baluta@intel.com>,
	Michael Welling <mwelling@ieee.org>
Cc: Hartmut Knaack <knaack.h@gmx.de>,
	Lars-Peter Clausen <lars@metafoo.de>,
	Peter Meerwald-Stadler <pmeerw@pmeerw.net>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
	Lucas De Marchi <lucas.demarchi@intel.com>,
	linux@roeck-us.net, eibach@gdsys.de
Subject: Re: [PATCH v3] iio: adc: Add TI ADS1015 ADC driver support
Date: Sat, 6 Feb 2016 18:12:15 +0000	[thread overview]
Message-ID: <56B6377F.10807@kernel.org> (raw)
In-Reply-To: <CAEnQRZDOPYDVUUXBXc7OEmAo0QEryg0PvMLXUxA__Rxu8bS=0g@mail.gmail.com>

On 04/02/16 12:51, Daniel Baluta wrote:
>> Would it be more consistent to handle the mutex outside of the switch above similar
>> to how it is handled in ads1015_write_raw?
>>
>> Also the ads1015_set_power_state(data, false) is called either way so why not just
>> use one call?
>>
> 
> I don't have a strong preference for that. I think across IIO drivers
> we can find both coding practices.
Often we move it into the switch because in most driver some of the read_raw
elements don't need to query the hardware (scales are often fixed for example) so
we don't need to take the lock for them.  Here it makes sense to take the lock.

(Not that I care much either way!)
> 
> Indeed consistency with ads1015_write_raw is a good argument. Will fix it.
> 
> I will leave the code here for one more day and then send an updated version.
> 
> thanks,
> Daniel.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

  reply	other threads:[~2016-02-06 18:12 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-03 16:59 [PATCH v3] iio: adc: Add TI ADS1015 ADC driver support Daniel Baluta
2016-02-03 18:19 ` Michael Welling
2016-02-04 12:51   ` Daniel Baluta
2016-02-06 18:12     ` Jonathan Cameron [this message]
2016-02-04  1:00 ` Matt Ranostay

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=56B6377F.10807@kernel.org \
    --to=jic23@kernel.org \
    --cc=daniel.baluta@intel.com \
    --cc=eibach@gdsys.de \
    --cc=knaack.h@gmx.de \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=lucas.demarchi@intel.com \
    --cc=mwelling@ieee.org \
    --cc=pmeerw@pmeerw.net \
    /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).