On 22.01.2024 20:09, Jason Andryuk wrote: > When HWP is active, the cpufreq P-state information is not updated. In > that case, return -ENODEV instead of bogus, incomplete info. The xenpm > command already supports skipping results when -ENODEV is returned, so > it is re-used when -EOPNOTSUPP might be more accurate. > > Similarly, set_cpufreq_para() is not applicable when HWP is active. > Many of the options already checked the governor and were inaccessible, > but SCALING_MIN/MAX_FREQ was still accessible (though it would do > nothing). Add an ealier HWP check to handle all cases. > > Signed-off-by: Jason Andryuk <jandr...@gmail.com> > --- > `xenpm get-cpufreq-states` now doesn't return any output. It also exits > successfully since xenpm doesn't check the returns there.
This isn't very nice. Is there nothing sensible that can be output instead in the HWP case? If not, I think it would help if inapplicability of the command would be indicated by at least one line of output. Or might it make sense to at least fall back to get-cpufreq-average in that case? > Other > commands will fail: > xenpm set-scaling-maxfreq 11 1100000 > failed to set scaling max freq (95 - Operation not supported) This is fine imo. Jan
