Re: [PATCH 0/3] Improve usability for amd-pstate

[Huang Rui <ray.huang@amd.com>]

On Fri, Mar 25, 2022 at 01:42:25PM +0800, Limonciello, Mario wrote:
> There has recently been some news coverage about `amd-pstate` being in
> 5.17, but this news also mentioned that it's a bit difficult to use.
> 
> You need to either block init calls, or compile the module into the kernel
> to force it to take precedence over acpi-cpufreq.
> 
> This series aims to improve the usability of amd-pstate so that distros
> can compile as a module, but users can still use it (relatively) easily.
> 
> A new module parameter is included that will force amd-pstate to take
> precedence and a module table to let it load automatically on such systems.
> 
> With the patches in this series a user can make a file
> /etc/modprobe.d/amd-pstate.conf:
> 
> options amd-pstate replace=1

Actually, because the amd-pstate is fairly new for current distos, we can
modify /etc/modules-load.d/modules.conf to add one line "amd_pstate" to
inform the system this module should be loaded at boot time.

But your method also looks fine for me as well, the amd-pstate can force to
replace the acpi-cpufreq. I am not sure whether anyone objects to this way.

Thanks,
Ray

> 
> Then upon the next reboot amd-pstate should load automatically even if
> acpi-cpufreq was included on the system.
> Mario Limonciello (3):
>   cpufreq: Allow passing NULL as the argument for unregistering a driver
>   cpufreq: amd-pstate: Allow replacing existing cpufreq drivers when
>     loaded
>   cpufreq: amd-pstate: Add a module device table
> 
>  drivers/cpufreq/amd-pstate.c | 19 ++++++++++++++++---
>  drivers/cpufreq/cpufreq.c    |  4 ++--
>  2 files changed, 18 insertions(+), 5 deletions(-)
> 
> -- 
> 2.34.1
>