[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20140604123300.GI2520@sirena.org.uk>
Date: Wed, 4 Jun 2014 13:33:00 +0100
From: Mark Brown <broonie@...nel.org>
To: Viresh Kumar <viresh.kumar@...aro.org>
Cc: "Rafael J. Wysocki" <rjw@...ysocki.net>,
Lists linaro-kernel <linaro-kernel@...ts.linaro.org>,
"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Arvind Chauhan <arvind.chauhan@....com>,
Eduardo Valentin <edubezval@...il.com>,
Pavel Machek <pavel@....cz>,
Liam Girdwood <lgirdwood@...il.com>
Subject: Re: [PATCH 1/2] regulators: Add definition of
regulator_set_voltage_time() for !CONFIG_REGULATOR
On Wed, Jun 04, 2014 at 04:27:48PM +0530, Viresh Kumar wrote:
> On 4 June 2014 16:08, Mark Brown <broonie@...nel.org> wrote:
> > Please, go and *think* about what's going on here. I've repeatedly
> > If the code fails to change the voltage it needs to handle that
> > (including remembering that attempts to lower the voltage fail); if the
> > code handles the errors sensibly I would expect that to handle
> > everything.
> That's what I was asking, how should the code handle it? Code also
> has to take care of platforms which haven't configured regulators
> in kernel and want to use this generic driver.
If the code gets an error back when it tries to change the voltage then
it should assume that the attempt to change the voltage did not succeed.
Should an attempt to change the voltage not succeed it seems reasonable
to assume that the voltage did not change and is the same as before.
The obvious thing would therefore appear to be for the code to proceed
with that assumption and act accordingly.
Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)
Powered by blists - more mailing lists