Skip to contentSkip to conversation

handle fadt->si_cmd == 0

PATCH In review Jesse Barnes 2 participants 2 messages Jun 6, 2003 – Jun 9, 2003 1 message not in the archive

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 handle fadt->si_cmd == 0

In reading the spec, it looks like if a particular ACPI implementation leaves fadt->si_cmd equal to 0, that means the platform doesn't support system management mode, which seems legal. I needed this patch for my system. With the patch applied, I'm able to see /proc/acpi and the interpreter appears to start. Is this legal?

Thanks,
Jesse

drivers/acpi/hardware/hwacpi.c renamed from usr/tmp/TmpDir.30375-0/linux/drivers/acpi/hardware/hwacpi.c_1.10 +4 -0
@@ -180,6 +180,10 @@
 
 	ACPI_FUNCTION_TRACE ("Hw_get_mode");
 
+	/* If there's no smi_cmd port, then it's ACPI only hw */
+	if (!acpi_gbl_FADT->smi_cmd)
+		return_VALUE (ACPI_SYS_MODE_ACPI);
+
 	status = acpi_get_register (ACPI_BITREG_SCI_ENABLE, &value, ACPI_MTX_LOCK);
 	if (ACPI_FAILURE (status)) {
 		return_VALUE (ACPI_SYS_MODE_LEGACY);

-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com.

A message that is not in the archive (sent off-list or not yet received): 20030606171730.GD1349-sJ/[email protected]

#2 lore raw

Hi Jesse,

From: jbarnes-sJ/[email protected] (Jesse Barnes)
Subject: [ACPI] [PATCH] handle fadt->si_cmd == 0
Date: Fri, 6 Jun 2003 10:17:30 -0700
Message-ID: <20030606171730.GD1349-sJ/[email protected]>

Quoted 5 lines

In reading the spec, it looks like if a particular ACPI implementation leaves fadt->si_cmd equal to 0, that means the platform doesn't support system management mode, which seems legal. I needed this patch for my system. With the patch applied, I'm able to see /proc/acpi and the interpreter appears to start. Is this legal?

Once there was an exactly same discussion, and the current implementation is correct. As you wrote, the meaning of value 0 in smi_cmd field in the FADT is clarified in the ACPI spec 2.0 and this is implemented in acpi_hw_set_mode().

But in any case, SCI_ENABLE bit in PM1 control register should be set correctly, reflecting the system state. If your platform specifies smi_cmd is 0 and SCI_ENABLE is 'enabled', the ACPI subsystem won't try to call acpi_hw_set_mode() to enable ACPI mode (as it's already in ACPI mode).

IIRC, once there was the same workaround in the ia64 patch for some (prototype?) HP machines.

Quoted 16 lines
drivers/acpi/hardware/hwacpi.c renamed from usr/tmp/TmpDir.30375-0/linux/drivers/acpi/hardware/hwacpi.c_1.10 +4 -1
@@ -180,6 +180,10 @@
 
 	ACPI_FUNCTION_TRACE ("Hw_get_mode");
 
+	/* If there's no smi_cmd port, then it's ACPI only hw */
+	if (!acpi_gbl_FADT->smi_cmd)
+		return_VALUE (ACPI_SYS_MODE_ACPI);
+
 	status = acpi_get_register (ACPI_BITREG_SCI_ENABLE, &value, ACPI_MTX_LOCK);
 	if (ACPI_FAILURE (status)) {
 		return_VALUE (ACPI_SYS_MODE_LEGACY);
 
 
-------------------------------------------------------
Quoted 8 lines

This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com.
_______________________________________________
Acpi-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/acpi-devel

-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com.