aboutsummaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/bin/export-to-postgresql-report
diff options
context:
space:
mode:
authorChristian Marangi <[email protected]>2022-06-20 00:03:51 +0200
committerChanwoo Choi <[email protected]>2022-06-30 05:11:17 +0900
commitb5d281f6c16dd432b618bdfd36ddba1a58d5b603 (patch)
tree0c284f1e8dee4aedc13b1e9d39d569d745f2ac60 /tools/perf/scripts/python/bin/export-to-postgresql-report
parentf44b799603a9b5d2e375b0b2d54dd0b791eddfc2 (diff)
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: [email protected] Signed-off-by: Christian Marangi <[email protected]> Signed-off-by: Chanwoo Choi <[email protected]>
Diffstat (limited to 'tools/perf/scripts/python/bin/export-to-postgresql-report')
0 files changed, 0 insertions, 0 deletions