[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKohpomj5-tHPkBLMrgGpsDCaCxW-8hGMunMTmJgXGgEgTR=vA@mail.gmail.com>
Date: Mon, 2 Jun 2014 15:45:37 +0530
From: Viresh Kumar <viresh.kumar@...aro.org>
To: Mark Brown <broonie@...nel.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 2 June 2014 15:32, Mark Brown <broonie@...nel.org> wrote:
> No, think about what you're changing here. You're changing the stub -
> the stub has a regulator_get() which always succeeeds.
Right, things might start to break with the change to
regulator_set_voltage()..
When I compare this to clk-APIs, the dummy implementations always
pass and so we are allowed to send NULL clk to any routine (the way
we can do it here, probably to simply code)..
Now, why do we want to return -EINVAL from set_voltage here ? Similar
routines in clk-API are returning 0 and even clk_get_rate() returns zero,
unlike in regulators, as we return -EINVAL..
Not sure which of these frameworks is doing the right thing.
What do you suggest.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists