handle fadt->si_cmd == 0
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]
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_cmdequal 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/acpiand 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.