From: Mike Turquette <mturquette@linaro.org>
To: Stephen Boyd <sboyd@codeaurora.org>,
Viresh Kumar <viresh.kumar@linaro.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
Shawn Guo <shawn.guo@linaro.org>,
Lists linaro-kernel <linaro-kernel@lists.linaro.org>,
"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Arvind Chauhan <arvind.chauhan@arm.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
linux-arm-msm@vger.kernel.org, Sachin Kamat <spk.linux@gmail.com>,
Thomas P Abraham <thomas.ab@samsung.com>,
Nishanth Menon <nm@ti.com>, Tomasz Figa <t.figa@samsung.com>,
Mark Brown <broonie@kernel.org>,
Mark Rutland <Mark.Rutland@arm.com>
Subject: Re: [PATCH 2/2] cpufreq: cpu0: Extend support beyond CPU0
Date: Thu, 26 Jun 2014 18:53:54 -0700 [thread overview]
Message-ID: <20140627015354.32686.83046@quantum> (raw)
In-Reply-To: <53ACB568.4000903@codeaurora.org>
Quoting Stephen Boyd (2014-06-26 17:06:00)
> Finally, checking for equivalent pointers from clk_get() will work now,
Please don't do that. Even though it works for the current
implementation, comparing those pointers from a driver violates how
clkdev is supposed to work. The pointer returned by clk_get should only
be dereferenced by a driver to check if it is an error code. Anything
besides an error code is no business of the driver.
> but it isn't future-proof if/when the clock framework starts returning
> dynamically allocated clock pointers for each clk_get() invocation.
> Maybe we need a function in the common clock framework that tells us if
> the clocks are the same either via DT or by taking two clock pointers?
I looked through the patch briefly and did not see why we would need to
do this. Any hint?
Thanks,
Mike
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> hosted by The Linux Foundation
>
WARNING: multiple messages have this Message-ID (diff)
From: mturquette@linaro.org (Mike Turquette)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2] cpufreq: cpu0: Extend support beyond CPU0
Date: Thu, 26 Jun 2014 18:53:54 -0700 [thread overview]
Message-ID: <20140627015354.32686.83046@quantum> (raw)
In-Reply-To: <53ACB568.4000903@codeaurora.org>
Quoting Stephen Boyd (2014-06-26 17:06:00)
> Finally, checking for equivalent pointers from clk_get() will work now,
Please don't do that. Even though it works for the current
implementation, comparing those pointers from a driver violates how
clkdev is supposed to work. The pointer returned by clk_get should only
be dereferenced by a driver to check if it is an error code. Anything
besides an error code is no business of the driver.
> but it isn't future-proof if/when the clock framework starts returning
> dynamically allocated clock pointers for each clk_get() invocation.
> Maybe we need a function in the common clock framework that tells us if
> the clocks are the same either via DT or by taking two clock pointers?
I looked through the patch briefly and did not see why we would need to
do this. Any hint?
Thanks,
Mike
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> hosted by The Linux Foundation
>
next prev parent reply other threads:[~2014-06-27 1:53 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-25 8:42 [PATCH 0/2] cpufreq: cpu0: Extend support beyond CPU0 Viresh Kumar
2014-06-25 8:42 ` 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 ` Viresh Kumar
2014-06-25 8:42 ` [PATCH 2/2] cpufreq: cpu0: Extend support beyond CPU0 Viresh Kumar
2014-06-25 8:42 ` Viresh Kumar
2014-06-25 19:02 ` Stephen Boyd
2014-06-25 19:02 ` Stephen Boyd
2014-06-26 1:55 ` Viresh Kumar
2014-06-26 1:55 ` Viresh Kumar
2014-06-26 7:34 ` Viresh Kumar
2014-06-26 7:34 ` Viresh Kumar
2014-06-26 10:52 ` Viresh Kumar
2014-06-26 10:52 ` Viresh Kumar
2014-06-27 0:06 ` Stephen Boyd
2014-06-27 0:06 ` Stephen Boyd
2014-06-27 1:53 ` Mike Turquette [this message]
2014-06-27 1:53 ` Mike Turquette
2014-06-27 2:15 ` Viresh Kumar
2014-06-27 2:15 ` Viresh Kumar
2014-06-30 7:57 ` Viresh Kumar
2014-06-30 7:57 ` Viresh Kumar
2014-06-30 18:33 ` Rob Herring
2014-06-30 18:33 ` Rob Herring
2014-07-01 11:14 ` Viresh Kumar
2014-07-01 11:14 ` Viresh Kumar
2014-07-01 22:00 ` Mike Turquette
2014-07-01 22:00 ` Mike Turquette
2014-07-02 3:32 ` Viresh Kumar
2014-07-02 3:32 ` Viresh Kumar
2014-06-27 2:26 ` Viresh Kumar
2014-06-27 2:26 ` Viresh Kumar
2014-06-26 22:08 ` Mark Brown
2014-06-26 22:08 ` Mark Brown
2014-06-28 14:52 ` Shawn Guo
2014-06-28 14:52 ` Shawn Guo
2014-06-28 14:52 ` Shawn Guo
2014-06-30 4:50 ` Viresh Kumar
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=20140627015354.32686.83046@quantum \
--to=mturquette@linaro.org \
--cc=Mark.Rutland@arm.com \
--cc=arvind.chauhan@arm.com \
--cc=broonie@kernel.org \
--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=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 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.