From: Mark Brown <broonie@kernel.org>
To: Stephen Boyd <sboyd@codeaurora.org>
Cc: Viresh Kumar <viresh.kumar@linaro.org>,
rjw@rjwysocki.net, shawn.guo@linaro.org,
linaro-kernel@lists.linaro.org, linux-pm@vger.kernel.org,
linux-kernel@vger.kernel.org, arvind.chauhan@arm.com,
mturquette@linaro.org, linux-arm-kernel@lists.infradead.org,
linux-arm-msm@vger.kernel.org, spk.linux@gmail.com,
thomas.ab@samsung.com, nm@ti.com, t.figa@samsung.com,
Mark Rutland <Mark.Rutland@arm.com>
Subject: Re: [PATCH 2/2] cpufreq: cpu0: Extend support beyond CPU0
Date: Thu, 26 Jun 2014 23:08:23 +0100 [thread overview]
Message-ID: <20140626220823.GA23300@sirena.org.uk> (raw)
In-Reply-To: <53AB1CC1.4010907@codeaurora.org>
[-- Attachment #1: Type: text/plain, Size: 690 bytes --]
On Wed, Jun 25, 2014 at 12:02:25PM -0700, Stephen Boyd wrote:
> I don't think this driver should be using regulator_get_optional() (Mark
> B. please correct me if I'm wrong). I doubt a supply is actually
> optional for CPUs, just some DTs aren't specifying them. In those cases,
> the regulator core will insert a dummy supply and the code will work
> without having to check for probe defer and error pointers.
Since the cpufreq driver is actively working with the regulator,
changing voltages and so on it's mostly OK, it's kind of on the border
of something that should do this but there doesn't seem to be a
reasonable way for it to handle not being able to read the voltage
cleanly.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2014-06-26 22:09 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-25 8:42 [PATCH 0/2] " Viresh Kumar
2014-06-25 8:42 ` [PATCH 1/2] cpufreq: Add support for per-policy driver data Viresh Kumar
2014-06-25 8:42 ` [PATCH 2/2] cpufreq: cpu0: Extend support beyond CPU0 Viresh Kumar
2014-06-25 19:02 ` Stephen Boyd
2014-06-26 1:55 ` Viresh Kumar
2014-06-26 7:34 ` Viresh Kumar
2014-06-26 10:52 ` Viresh Kumar
2014-06-27 0:06 ` Stephen Boyd
2014-06-27 1:53 ` Mike Turquette
2014-06-27 2:15 ` Viresh Kumar
2014-06-30 7:57 ` Viresh Kumar
2014-06-30 18:33 ` Rob Herring
2014-07-01 11:14 ` Viresh Kumar
2014-07-01 22:00 ` Mike Turquette
2014-07-02 3:32 ` Viresh Kumar
2014-06-27 2:26 ` Viresh Kumar
2014-06-26 22:08 ` Mark Brown [this message]
2014-06-28 14:52 ` Shawn Guo
2014-06-30 4:50 ` Viresh Kumar
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=20140626220823.GA23300@sirena.org.uk \
--to=broonie@kernel.org \
--cc=Mark.Rutland@arm.com \
--cc=arvind.chauhan@arm.com \
--cc=linaro-kernel@lists.linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mturquette@linaro.org \
--cc=nm@ti.com \
--cc=rjw@rjwysocki.net \
--cc=sboyd@codeaurora.org \
--cc=shawn.guo@linaro.org \
--cc=spk.linux@gmail.com \
--cc=t.figa@samsung.com \
--cc=thomas.ab@samsung.com \
--cc=viresh.kumar@linaro.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
all inboxes | Powered by JetHome®