Revision b5d281f6c16dd432b618bdfd36ddba1a58d5b603 authored by Christian Marangi on 19 June 2022, 22:03:51 UTC, committed by Chanwoo Choi on 29 June 2022, 20:11:17 UTC
On a devfreq PROBE_DEFER, the freq_table in the driver profile struct,
is never reset and may be leaved in an undefined state.

This comes from the fact that we store the freq_table in the driver
profile struct that is commonly defined as static and not reset on
PROBE_DEFER.
We currently skip the reinit of the freq_table if we found
it's already defined since a driver may declare his own freq_table.

This logic is flawed in the case devfreq core generate a freq_table, set
it in the profile struct and then PROBE_DEFER, freeing the freq_table.
In this case devfreq will found a NOT NULL freq_table that has been
freed, skip the freq_table generation and probe the driver based on the
wrong table.

To fix this and correctly handle PROBE_DEFER, use a local freq_table and
max_state in the devfreq struct and never modify the freq_table present
in the profile struct if it does provide it.

Fixes: 0ec09ac2cebe ("PM / devfreq: Set the freq_table of devfreq device")
Cc: stable@vger.kernel.org
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
1 parent f44b799
History
File Mode Size
test
.gitignore -rw-r--r-- 106 bytes
Makefile -rw-r--r-- 3.3 KB
algos.c -rw-r--r-- 6.2 KB
altivec.uc -rw-r--r-- 3.3 KB
avx2.c -rw-r--r-- 16.9 KB
avx512.c -rw-r--r-- 17.8 KB
int.uc -rw-r--r-- 3.7 KB
mktables.c -rw-r--r-- 3.9 KB
mmx.c -rw-r--r-- 3.6 KB
neon.c -rw-r--r-- 2.0 KB
neon.uc -rw-r--r-- 3.8 KB
recov.c -rw-r--r-- 3.3 KB
recov_avx2.c -rw-r--r-- 8.8 KB
recov_avx512.c -rw-r--r-- 9.4 KB
recov_neon.c -rw-r--r-- 2.6 KB
recov_neon_inner.c -rw-r--r-- 2.3 KB
recov_s390xc.c -rw-r--r-- 2.7 KB
recov_ssse3.c -rw-r--r-- 9.0 KB
s390vx.uc -rw-r--r-- 3.8 KB
sse1.c -rw-r--r-- 4.6 KB
sse2.c -rw-r--r-- 15.8 KB
unroll.awk -rw-r--r-- 423 bytes
vpermxor.uc -rw-r--r-- 2.7 KB
x86.h -rw-r--r-- 2.1 KB

back to top