From: Arnd Bergmann <arnd@arndb.de>
To: linaro-kernel@lists.linaro.org
Cc: Mark Brown <broonie@kernel.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:12:39 +0100 [thread overview]
Message-ID: <10492578.n5ZTGbvbYE@wuerfel> (raw)
In-Reply-To: <20160216131108.GK18327@sirena.org.uk>
On Tuesday 16 February 2016 13:11:08 Mark Brown wrote:
> On Tue, Feb 16, 2016 at 10:10:44AM +0100, Arnd Bergmann wrote:
> > On Tuesday 16 February 2016 01:56:16 Mark Brown wrote:
>
> > > No, NULL is explicitly not something you can substitute in,
> > > essentially all the users are just not bothering to implement error
> > > checking and we don't want to encourage that. The set of use cases
> > > where we legitimately have optional supplies is very small, much smaller
> > > than clocks, because it makes the electrical engineering a lot harder.
>
> > I must have misinterpreted the idea behind that API as well then.
>
> > From this function definition:
>
> > static inline struct regulator *__must_check regulator_get(struct device *dev,
> > const char *id)
> > {
> > /* Nothing except the stubbed out regulator API should be
> > * looking at the value except to check if it is an error
> > * value. Drivers are free to handle NULL specifically by
> > * skipping all regulator API calls, but they don't have to.
> > * Drivers which don't, should make sure they properly handle
> > * corner cases of the API, such as regulator_get_voltage()
> > * returning 0.
> > */
> > return NULL;
> > }
>
> This is the stubbed regulator API which is only ever used with the stub
> regulator API, it uses NULL to give a non-error pointer it can return to
> well written callers so they don't know they are running with the stubs.
> We are explicitly using NULL because callers should treat it as a valid
> regulator.
Right, that is what I understood.
> > my reading was that the expected behavior in any driver was:
>
> > * call regulator_get()
> > * if IS_ERR(), fail device probe function, never use invalid
> > pointer other than PTR_ERR()
> > * if NULL, and regulator is required, fail probe so we never
> > use the regulator
>
> No, drivers should never look at the value of the pointer other than to
> check it for error. If there is a problem of any kind an error will be
> returned.
>
> > * if NULL, and regulators are optional, continue with the NULL
> > value.
>
> 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).
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.
Arnd
next prev parent reply other threads:[~2016-02-16 15:13 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-11 11:25 [PATCH] PM / OPP: Fix NULL pointer dereference crash when disabling OPPs Jon Hunter
[not found] ` <1455189959-27944-1-git-send-email-jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2016-02-11 11:34 ` Viresh Kumar
2016-02-11 11:34 ` Viresh Kumar
2016-02-11 21:16 ` Rafael J. Wysocki
2016-02-15 13:59 ` [PATCH] PM / OPP: Fix NULL pointer dereference crash when setting the OPP Jon Hunter
[not found] ` <1455544758-7718-1-git-send-email-jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2016-02-15 16:25 ` Viresh Kumar
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: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 [this message]
2016-02-16 16:51 ` Mark Brown
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=10492578.n5ZTGbvbYE@wuerfel \
--to=arnd@arndb.de \
--cc=broonie@kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.