diff options
author | Rafael J. Wysocki <rafael.j.wysocki@intel.com> | 2019-11-20 10:33:34 +0100 |
---|---|---|
committer | Rafael J. Wysocki <rafael.j.wysocki@intel.com> | 2019-11-20 10:46:42 +0100 |
commit | 05ff1ba412fd6bd48d56dd4c0baff626533728cc (patch) | |
tree | 4f3eadae0d2a5e2e7268cbc053384b0086cca6fd /drivers/gnss/sirf.c | |
parent | af42d3466bdc8f39806b26f593604fdc54140bcb (diff) | |
download | talos-op-linux-05ff1ba412fd6bd48d56dd4c0baff626533728cc.tar.gz talos-op-linux-05ff1ba412fd6bd48d56dd4c0baff626533728cc.zip |
PM: QoS: Invalidate frequency QoS requests after removal
Switching cpufreq drivers (or switching operation modes of the
intel_pstate driver from "active" to "passive" and vice versa)
does not work on some x86 systems with ACPI after commit
3000ce3c52f8 ("cpufreq: Use per-policy frequency QoS"), because
the ACPI _PPC and thermal code uses the same frequency QoS request
object for a given CPU every time a cpufreq driver is registered
and freq_qos_remove_request() does not invalidate the request after
removing it from its QoS list, so freq_qos_add_request() complains
and fails when that request is passed to it again.
Fix the issue by modifying freq_qos_remove_request() to clear the qos
and type fields of the frequency request pointed to by its argument
after removing it from its QoS list so as to invalidate it.
Fixes: 3000ce3c52f8 ("cpufreq: Use per-policy frequency QoS")
Reported-and-tested-by: Doug Smythies <dsmythies@telus.net>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Diffstat (limited to 'drivers/gnss/sirf.c')
0 files changed, 0 insertions, 0 deletions