Commit Message

From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
On POWERNV platform, Pstates are 8-bit values. On POWER8 they are
negatively numbered while on POWER9 they are positively
numbered. Thus, on POWER9, the maximum number of pstates could be as
high as 256.
The current code interprets pstates as a signed 8-bit value. This
causes a problem on POWER9 platforms which have more than 128 pstates.
On such systems, on a CPU that is in a lower pstate whose number is
greater than 128, querying the current pstate returns a "pstate X is
out of bound" error message and the current pstate is reported as the
nominal pstate.
This patch fixes the aforementioned issue by correctly differentiating
the sign whenever a pstate value read, depending on whether the
pstates are positively numbered or negatively numbered.
Fixes: commit 09ca4c9b5958 ("cpufreq: powernv: Replacing pstate_id with frequency table index")
Cc: <stable@vger.kernel.org> #v4.8
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Tested-and-reviewed-by: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
---
drivers/cpufreq/powernv-cpufreq.c | 43 ++++++++++++++++++++++++++++++---------
1 file changed, 33 insertions(+), 10 deletions(-)

"Rafael J. Wysocki" <rafael@kernel.org> writes:
> On Thu, Dec 7, 2017 at 6:59 AM, Gautham R. Shenoy> <ego@linux.vnet.ibm.com> wrote:>> From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>>>>> On POWERNV platform, Pstates are 8-bit values. On POWER8 they are>> negatively numbered while on POWER9 they are positively>> numbered. Thus, on POWER9, the maximum number of pstates could be as>> high as 256.>>>> The current code interprets pstates as a signed 8-bit value. This>> causes a problem on POWER9 platforms which have more than 128 pstates.>> On such systems, on a CPU that is in a lower pstate whose number is>> greater than 128, querying the current pstate returns a "pstate X is>> out of bound" error message and the current pstate is reported as the>> nominal pstate.>>>> This patch fixes the aforementioned issue by correctly differentiating>> the sign whenever a pstate value read, depending on whether the>> pstates are positively numbered or negatively numbered.>>>> Fixes: commit 09ca4c9b5958 ("cpufreq: powernv: Replacing pstate_id with frequency table index")>> Cc: <stable@vger.kernel.org> #v4.8>> Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>>> Tested-and-reviewed-by: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>>> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>>> I'm going to apply this, or please let me know if you want to route it> differently.
Do you mind waiting for now, we're still debating how to fix it.
cheers

On Fri, Dec 8, 2017 at 12:47 PM, Michael Ellerman <mpe@ellerman.id.au> wrote:
> "Rafael J. Wysocki" <rafael@kernel.org> writes:>>> On Thu, Dec 7, 2017 at 6:59 AM, Gautham R. Shenoy>> <ego@linux.vnet.ibm.com> wrote:>>> From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>>>>>>> On POWERNV platform, Pstates are 8-bit values. On POWER8 they are>>> negatively numbered while on POWER9 they are positively>>> numbered. Thus, on POWER9, the maximum number of pstates could be as>>> high as 256.>>>>>> The current code interprets pstates as a signed 8-bit value. This>>> causes a problem on POWER9 platforms which have more than 128 pstates.>>> On such systems, on a CPU that is in a lower pstate whose number is>>> greater than 128, querying the current pstate returns a "pstate X is>>> out of bound" error message and the current pstate is reported as the>>> nominal pstate.>>>>>> This patch fixes the aforementioned issue by correctly differentiating>>> the sign whenever a pstate value read, depending on whether the>>> pstates are positively numbered or negatively numbered.>>>>>> Fixes: commit 09ca4c9b5958 ("cpufreq: powernv: Replacing pstate_id with frequency table index")>>> Cc: <stable@vger.kernel.org> #v4.8>>> Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>>>> Tested-and-reviewed-by: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>>>> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>>>>> I'm going to apply this, or please let me know if you want to route it>> differently.>> Do you mind waiting for now, we're still debating how to fix it.
No problem. :-)
Just please let me know when you're ready.