summaryrefslogtreecommitdiffstats
path: root/drivers/crypto/omap-crypto.c
diff options
context:
space:
mode:
authorRafael J. Wysocki <rafael.j.wysocki@intel.com>2019-11-20 10:33:34 +0100
committerRafael J. Wysocki <rafael.j.wysocki@intel.com>2019-11-20 10:46:42 +0100
commit05ff1ba412fd6bd48d56dd4c0baff626533728cc (patch)
tree4f3eadae0d2a5e2e7268cbc053384b0086cca6fd /drivers/crypto/omap-crypto.c
parentaf42d3466bdc8f39806b26f593604fdc54140bcb (diff)
downloadtalos-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/crypto/omap-crypto.c')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud