From: Mark Brown <broonie@kernel.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: linaro-kernel@lists.linaro.org, Nishanth Menon <nm@ti.com>,
linux-pm@vger.kernel.org, Viresh Kumar <viresh.kumar@linaro.org>,
Rafael Wysocki <rjw@rjwysocki.net>,
linux-kernel@vger.kernel.org, Jon Hunter <jonathanh@nvidia.com>,
Viresh Kumar <vireshk@kernel.org>,
Stephen Boyd <sboyd@codeaurora.org>
Subject: Re: [PATCH] PM / OPP: Initialize regulator pointer to an error value
Date: Tue, 16 Feb 2016 16:51:35 +0000 [thread overview]
Message-ID: <20160216165135.GB7544@sirena.org.uk> (raw)
In-Reply-To: <10492578.n5ZTGbvbYE@wuerfel>
[-- Attachment #1: Type: text/plain, Size: 1087 bytes --]
On Tue, Feb 16, 2016 at 04:12:39PM +0100, Arnd Bergmann wrote:
> On Tuesday 16 February 2016 13:11:08 Mark Brown wrote:
> > No, we always return an error pointer if we fail to get a regulator.
> > The difference with optional regulators is in how we handle the
> > situation where we have full constraints and a regulator is not mapped
> > in, normally we assume there must be one with no software control but we
> > need to work around buggy bindings as the device would be non-functional
> > without power.
> Sorry, I should not have said "optional" here, which has a specific
> meaning in the API. I meant a driver that can work with either
> CONFIG_REGULATOR enabled or disabled (which is something slightly
> different).
Ah, right!
> I guess a driver needing to know whether regulators are built-in
> should check 'if (IS_ENABLED(CONFIG_REGULATOR))' rather than
> checking the return code for NULL.
Yes, that's the expected interface here if anyone does need to check
although for most users it's expected that the stubs will be sufficient
and they don't need to check at all.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
prev parent reply other threads:[~2016-02-16 16:51 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1455544758-7718-1-git-send-email-jonathanh@nvidia.com>
2016-02-15 16:26 ` [PATCH] PM / OPP: Initialize regulator pointer to an error value Viresh Kumar
2016-02-15 16:42 ` Jon Hunter
2016-02-15 16:44 ` Viresh Kumar
2016-02-15 20:38 ` Arnd Bergmann
2016-02-15 21:13 ` Rafael J. Wysocki
2016-02-16 0:47 ` Viresh Kumar
2016-02-16 0:50 ` Rafael J. Wysocki
2016-02-16 1:00 ` Viresh Kumar
2016-02-16 1:56 ` Mark Brown
2016-02-16 9:10 ` Arnd Bergmann
2016-02-16 13:11 ` Mark Brown
2016-02-16 15:12 ` Arnd Bergmann
2016-02-16 16:51 ` Mark Brown [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=20160216165135.GB7544@sirena.org.uk \
--to=broonie@kernel.org \
--cc=arnd@arndb.de \
--cc=jonathanh@nvidia.com \
--cc=linaro-kernel@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=nm@ti.com \
--cc=rjw@rjwysocki.net \
--cc=sboyd@codeaurora.org \
--cc=viresh.kumar@linaro.org \
--cc=vireshk@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