Re: [PATCH] platform/x86/amd/hsmp: add CONFIG_ACPI dependency

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 1/29/2024 07:24, Suma Hegde wrote:
HSMP interface is only supported on x86 based AMD EPYC line of
processors. Driver uses ACPI APIs, so make it dependent on CONFIG_ACPI.

Reported-by: kernel test robot <lkp@xxxxxxxxx>
Closes: https://lore.kernel.org/oe-kbuild-all/202401281437.aus91srb-lkp@xxxxxxxxx/
Signed-off-by: Suma Hegde <suma.hegde@xxxxxxx>
Signed-off-by: Naveen Krishna Chatradhi <naveen.krishna@xxxxxxx>
---

  drivers/platform/x86/amd/Kconfig | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/platform/x86/amd/Kconfig b/drivers/platform/x86/amd/Kconfig
index 54753213cc61..f88682d36447 100644
--- a/drivers/platform/x86/amd/Kconfig
+++ b/drivers/platform/x86/amd/Kconfig
@@ -8,7 +8,7 @@ source "drivers/platform/x86/amd/pmc/Kconfig"
config AMD_HSMP
  	tristate "AMD HSMP Driver"
-	depends on AMD_NB && X86_64
+	depends on AMD_NB && X86_64 && ACPI
  	help
  	  The driver provides a way for user space tools to monitor and manage
  	  system management functionality on EPYC server CPUs from AMD.

This specific patch looks fine to me.

Reviewed-by: Mario Limonciello <mario.limonciello@xxxxxxx>


However I would like to ask for some follow up code:

This driver is missing some safety checks that it really is running on EPYC. Probing registers that don't match the same mailboxes randomly on client or embedded parts might lead to unexpected behaviors.

I've seen when someone explicitly compiled with CONFIG_AMD_HSMP=y this breaks s0i3 on at least one system.

I have two suggestions:

1) Use something like amd-pstate does in init:

static bool amd_pstate_acpi_pm_profile_server(void)
{
	switch (acpi_gbl_FADT.preferred_profile) {
	case PM_ENTERPRISE_SERVER:
	case PM_SOHO_SERVER:
	case PM_PERFORMANCE_SERVER:
		return true;
	}
	return false;
}

2) If in non-ACPI mode, require that a user use a module parameter like "amd_hsmp.force=1" to load the driver.


Furthermore I noticed that your init call has a dev_err() that will show on unsupported parts. If someone compiles this driver into the kernel and runs it on one of these parts that's pretty noisy.

I suggest you downgrade this to debug.




[Index of Archives]     [Linux Kernel Development]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux