intel_pstate: Fix possible overflow complained by Coverity

Coverity scanning performed on intel_pstate.c shows possible
overflow when doing left shifting:
val = pstate << 8;
since pstate is of type integer, while val is of u64, left shifting
pstate might lead to potential loss of upper bits. Say, if pstate equals
0x4000 0000, after pstate << 8 we will get zero assigned to val.
Although pstate will not likely be that big, this patch cast the left
operand to u64 before performing the left shift, to avoid complaining
from Coverity.

Reported-by: Coquard, Christophe <christophe.coquard@intel.com>
Signed-off-by: Chen Yu <yu.c.chen@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index 7b2721fb861fba8bef63a23f37b93acba2dee3ac..b9354b6f71496bffc8460f87b38e4d58c4f2bc8b 100644 (file)
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -521,7 +521,7 @@ static void byt_set_pstate(struct cpudata *cpudata, int pstate)
        int32_t vid_fp;
        u32 vid;
 
-       val = pstate << 8;
+       val = (u64)pstate << 8;
        if (limits.no_turbo && !limits.turbo_disabled)
                val |= (u64)1 << 32;
 
@@ -610,7 +610,7 @@ static void core_set_pstate(struct cpudata *cpudata, int pstate)
 {
        u64 val;
 
-       val = pstate << 8;
+       val = (u64)pstate << 8;
        if (limits.no_turbo && !limits.turbo_disabled)
                val |= (u64)1 << 32;