diff options
author | Christian Marangi <ansuelsmth@gmail.com> | 2022-06-20 01:03:51 +0300 |
---|---|---|
committer | Chanwoo Choi <cw00.choi@samsung.com> | 2022-06-29 23:11:17 +0300 |
commit | b5d281f6c16dd432b618bdfd36ddba1a58d5b603 (patch) | |
tree | 0c284f1e8dee4aedc13b1e9d39d569d745f2ac60 /scripts/gdb/linux/proc.py | |
parent | f44b799603a9b5d2e375b0b2d54dd0b791eddfc2 (diff) | |
download | linux-b5d281f6c16dd432b618bdfd36ddba1a58d5b603.tar.xz |
PM / devfreq: Rework freq_table to be local to devfreq struct
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>
Diffstat (limited to 'scripts/gdb/linux/proc.py')
0 files changed, 0 insertions, 0 deletions