| Message ID | alpine.DEB.2.02.1312091812440.4127@tamien (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 10 December 2013 07:48, Paul Walmsley <pwalmsley@nvidia.com> wrote: > Treat both negative and zero return values from clk_round_rate() as errors. > This is needed since subsequent patches will convert clk_round_rate()'s > return value to be an unsigned type, rather than a signed type, since some > clock sources can generate rates higher than (2^31)-1 Hz. > > Eventually, when calling clk_round_rate(), only a return value of > zero will be considered a error. All other values will be > considered valid rates. The comparison against values less than > 0 is kept to preserve the correct behavior in the meantime. > > This patch also removes a bogus usage of IS_ERR_VALUE(), which is intended > to be used only on combination pointer/error code return values; a > side-benefit. > > Signed-off-by: Paul Walmsley <pwalmsley@nvidia.com> > Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> > Cc: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Monday 09 December 2013 09:18 PM, Paul Walmsley wrote: > > Treat both negative and zero return values from clk_round_rate() as errors. This is needed since subsequent patches will convert clk_round_rate()'s return value to be an unsigned type, rather than a signed type, since some clock sources can generate rates higher than (2^31)-1 Hz. > > Eventually, when calling clk_round_rate(), only a return value of > zero will be considered a error. All other values will be > considered valid rates. The comparison against values less than > 0 is kept to preserve the correct behavior in the meantime. > > This patch also removes a bogus usage of IS_ERR_VALUE(), which is intended to be used only on combination pointer/error code return values; a side-benefit. > > Signed-off-by: Paul Walmsley <pwalmsley@nvidia.com> > Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> > Cc: Viresh Kumar <viresh.kumar@linaro.org> > --- Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com> -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c index a0acd0bfba40..0f41eb2609f3 100644 --- a/drivers/cpufreq/omap-cpufreq.c +++ b/drivers/cpufreq/omap-cpufreq.c @@ -63,7 +63,7 @@ static int omap_target(struct cpufreq_policy *policy, unsigned int index) freq = new_freq * 1000; ret = clk_round_rate(mpu_clk, freq); - if (IS_ERR_VALUE(ret)) { + if (ret <= 0) { dev_warn(mpu_dev, "CPUfreq: Cannot find matching frequency for %lu\n", freq);
Treat both negative and zero return values from clk_round_rate() as errors. This is needed since subsequent patches will convert clk_round_rate()'s return value to be an unsigned type, rather than a signed type, since some clock sources can generate rates higher than (2^31)-1 Hz. Eventually, when calling clk_round_rate(), only a return value of zero will be considered a error. All other values will be considered valid rates. The comparison against values less than 0 is kept to preserve the correct behavior in the meantime. This patch also removes a bogus usage of IS_ERR_VALUE(), which is intended to be used only on combination pointer/error code return values; a side-benefit. Signed-off-by: Paul Walmsley <pwalmsley@nvidia.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Viresh Kumar <viresh.kumar@linaro.org> --- Applies on v3.13-rc3. See also: http://marc.info/?l=linux-arm-kernel&m=138542591313620&w=2 drivers/cpufreq/omap-cpufreq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html