[PATCH v3 6/6] cpufreq: amd-pstate: Default to replace acpi-cpufreq

[Mario Limonciello <mario.limonciello@amd.com>]

As a side effect of using the symbol `acpi_cpufreq_exit` attempting
to `modprobe amd-pstate` loads the acpi-cpufreq driver if it's compiled
as a module.

This means that module load order can't work anymore from those changes.
To make this a more obvious default behavior set the "replace" module
parameter for amd-pstate to true.

Expected outcome is that no matter what configuration for module or
compiled in, amd-pstate will take precedence.

If a user prefers to use acpi_cpufreq, they can set `amd_pstate.replace=0`
and then the following outcomes will happen when attempting to load
amd-pstate:
* acpi_cpufreq module  & amd_pstate module  -> acpi_cpufreq
* acpi_cpufreq builtin & amd_pstate module  -> acpi_cpufreq
* acpi_cpufreq builtin & amd_pstate builtin -> amd_pstate
* acpi_cpufreq module  & amd_pstate builtin -> amd_pstate

Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
---
v2->v3:
 * New patch, added since worse experience from patch 4.

 drivers/cpufreq/amd-pstate.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/cpufreq/amd-pstate.c b/drivers/cpufreq/amd-pstate.c
index 3330504b7070..538c9c4cea6d 100644
--- a/drivers/cpufreq/amd-pstate.c
+++ b/drivers/cpufreq/amd-pstate.c
@@ -64,7 +64,7 @@ MODULE_PARM_DESC(shared_mem,
 		 "enable amd-pstate on processors with shared memory solution (false = disabled (default), true = enabled)");
 
 #if defined(CONFIG_X86_ACPI_CPUFREQ) || defined(CONFIG_X86_ACPI_CPUFREQ_MODULE)
-static bool replace = false;
+static bool replace = true;
 module_param(replace, bool, 0444);
 MODULE_PARM_DESC(replace,
 		  "replace acpi-cpufreq driver upon init if necessary");
-- 
2.34.1