linux-iio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Cc: Lars-Peter Clausen <lars@metafoo.de>,
	Michael Hennerich <Michael.Hennerich@analog.com>,
	Hartmut Knaack <knaack.h@gmx.de>,
	Peter Meerwald <pmeerw@pmeerw.net>,
	linux-iio@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v5] iio: add ad5761 DAC driver
Date: Mon, 11 Jan 2016 19:21:05 +0000	[thread overview]
Message-ID: <569400A1.2060200@kernel.org> (raw)
In-Reply-To: <CAPybu_1oPAVtEyTOj6urZagvBf67Q8qwRC6vTsLa=Agi8t3f8A@mail.gmail.com>

On 11/01/16 16:23, Ricardo Ribalda Delgado wrote:
> Hello Jonathan
> 
> Thanks for your review
> 
> On Sat, Jan 9, 2016 at 5:15 PM, Jonathan Cameron <jic23@kernel.org> wrote:
>> I'm a little unsure that we shouldn't just fail the probe if the
>> range is supplied.  Even the default (the best option available)
>> could in theory do damage to a circuit with a maximum of 3V though
>> it's probably unlikely...
> 
> I personally hate when a driver needs a mandatory pdata. I expect a
> default behaviour on the absence of it.
That's fair enough, though in this particular case, in theory it could
cause damage.  Let's take the view that's unlikely.
> 
>>> +     st->vref_reg = devm_regulator_get_optional(&st->spi->dev, "vref");
>>> +     if (!st->vref_reg || PTR_ERR(st->vref_reg) == -ENODEV) {
>> This is a little unusual... Only one of those errors is returned by
>> devm_regulator_get_optional if the regulator is not specified.
>> I believe from a quick look at the regulator code that it returns the
>> -ENODEV part.
>>
>> So how can it be null?
>>
> 
> After a fast look:
> 
> devm_regulator_get_optional-> _devm_regulator_get -> regulator_get
> (regulator/consumer.h)
> 
> Probably consumer.h cannot be reached at the same time than
> _devm_regulator_get. But for safety I rather leave the check.
Hmm. In this particular case it's relatively clear that one of
the checks must be meaningless so chances of patches turning up
to 'fix' this in future makes me think it's better to save time
and drop it now.
> 
> 
> 
> I send v6 right away.
> 
> 
> Thanks!
> 
> 
> 


      reply	other threads:[~2016-01-11 19:21 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-08 17:29 [PATCH v5] iio: add ad5761 DAC driver Ricardo Ribalda Delgado
2016-01-09 16:15 ` Jonathan Cameron
2016-01-11 16:23   ` Ricardo Ribalda Delgado
2016-01-11 19:21     ` 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=569400A1.2060200@kernel.org \
    --to=jic23@kernel.org \
    --cc=Michael.Hennerich@analog.com \
    --cc=knaack.h@gmx.de \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pmeerw@pmeerw.net \
    --cc=ricardo.ribalda@gmail.com \
    /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).