[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20160216165135.GB7544@sirena.org.uk>
Date: Tue, 16 Feb 2016 16:51:35 +0000
From: Mark Brown <broonie@...nel.org>
To: Arnd Bergmann <arnd@...db.de>
Cc: linaro-kernel@...ts.linaro.org, Nishanth Menon <nm@...com>,
linux-pm@...r.kernel.org, Viresh Kumar <viresh.kumar@...aro.org>,
Rafael Wysocki <rjw@...ysocki.net>,
linux-kernel@...r.kernel.org, Jon Hunter <jonathanh@...dia.com>,
Viresh Kumar <vireshk@...nel.org>,
Stephen Boyd <sboyd@...eaurora.org>
Subject: Re: [PATCH] PM / OPP: Initialize regulator pointer to an error value
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.
Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)
Powered by blists - more mailing lists