ACPI: report "Module Device" support via _OSI
PATCH 2/2 ACPI: report "Module Device" support via _OSI
Update _OSI strings to report that "Module Device" is supported.
This is Linux-specific, so it should be one of the Linux divergences from the Intel ACPI CA.
drivers/acpi/utilities/uteval.c +3 -0
@@ -69,6 +69,9 @@/* Feature Group Strings */ "Extended Address Space Descriptor", +#ifdef CONFIG_ACPI_CONTAINER + "Module Device", +#endif };/* Local prototypes */
Hi,
I have a question. The ACPI container driver can be build as a kernel module. Should _OSI("Module Device") returns TRUE even when container driver module is not loaded? (Typically, _OSI is evaluated at _INI time, I think. So container driver module is not loaded at _OSI("Module Device") time anyway.)
Thanks,
Kenji Kaneshige
Quoted 26 lines · Bjorn Helgaas
Update
_OSIstrings to report that "Module Device" is supported.This is Linux-specific, so it should be one of the Linux divergences from the Intel ACPI CA.
Signed-off-by Bjorn Helgaas <[email protected]>Index:
work-mm5/drivers/acpi/utilities/uteval.c
===================================================================drivers/acpi/utilities/uteval.c +3
-1@@ -69,6 +69,9 @@/* Feature Group Strings */ "Extended Address Space Descriptor", +#ifdef CONFIG_ACPI_CONTAINER + "Module Device", +#endif };/* Local prototypes */ -To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 5 lines · Kenji Kaneshige
I have a question. The ACPI container driver can be build as a kernel module. Should
_OSI("Module Device")returns TRUE even when container driver module is not loaded? (Typically,_OSIis evaluated at_INItime, I think. So container driver module is not loaded at_OSI("Module Device")time anyway.)
Good question. I think _OSI("Module Device") should return true even if the container driver isn't loaded.
Do you think that's a bad idea?
I think it's OK if the namespace contains container devices that we ignore until the driver is loaded. Someday, the presence of those devices should be enough to cause udev to load the driver automatically. But for now, I think we have to do it manually.
Quoted 33 lines
Quoted 22 lines · Bjorn Helgaas
Update
_OSIstrings to report that "Module Device" is supported.This is Linux-specific, so it should be one of the Linux divergences from the Intel ACPI CA.
Signed-off-by Bjorn Helgaas <[email protected]>Index:
work-mm5/drivers/acpi/utilities/uteval.c
===================================================================drivers/acpi/utilities/uteval.c +3
-1@@ -69,6 +69,9 @@/* Feature Group Strings */ "Extended Address Space Descriptor", +#ifdef CONFIG_ACPI_CONTAINER + "Module Device", +#endif };/* Local prototypes */ -Quoted 4 lines
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 12 lines · Bjorn Helgaas
Quoted 5 lines · Kenji Kaneshige
I have a question. The ACPI container driver can be build as a kernel module. Should
_OSI("Module Device")returns TRUE even when container driver module is not loaded? (Typically,_OSIis evaluated at_INItime, I think. So container driver module is not loaded at_OSI("Module Device")time anyway.)Good question. I think
_OSI("Module Device")should return true even if the container driver isn't loaded.
Quoted 8 lines
Do you think that's a bad idea?
I think it's OK if the namespace contains container devices that we ignore until the driver is loaded. Someday, the presence of those devices should be enough to cause udev to load the driver automatically. But for now, I think we have to do it manually.
I see. I think you are right.
But now, I'm wondering why ACPI firmware needs _OSI("Module Device") because I think module devices in the namespace will be ignored by the OS if it doesn't support "Module Device"...
Anyway, thank you for your answer.
Thanks,
Kenji Kaneshige
Quoted 37 lines
Quoted 35 lines
Quoted 22 lines · Bjorn Helgaas
Update
_OSIstrings to report that "Module Device" is supported.This is Linux-specific, so it should be one of the Linux divergences from the Intel ACPI CA.
Signed-off-by Bjorn Helgaas <[email protected]>Index:
work-mm5/drivers/acpi/utilities/uteval.c
===================================================================drivers/acpi/utilities/uteval.c +3
-1@@ -69,6 +69,9 @@/* Feature Group Strings */ "Extended Address Space Descriptor", +#ifdef CONFIG_ACPI_CONTAINER + "Module Device", +#endif };/* Local prototypes */ -Quoted 4 lines
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 22 lines · Kenji Kaneshige
Quoted 12 lines · Bjorn Helgaas
Quoted 5 lines · Kenji Kaneshige
I have a question. The ACPI container driver can be build as a kernel module. Should
_OSI("Module Device")returns TRUE even when container driver module is not loaded? (Typically,_OSIis evaluated at_INItime, I think. So container driver module is not loaded at_OSI("Module Device")time anyway.)Good question. I think
_OSI("Module Device")should return true even if the container driver isn't loaded.Quoted 8 lines
Do you think that's a bad idea?
I think it's OK if the namespace contains container devices that we ignore until the driver is loaded. Someday, the presence of those devices should be enough to cause udev to load the driver automatically. But for now, I think we have to do it manually.
Quoted 5 lines
I see. I think you are right.
But now, I'm wondering why ACPI firmware needs
_OSI("Module Device")because I think module devices in the namespace will be ignored by the OS if it doesn't support "Module Device"...
I think the intent is that firmware might choose to expose some devices differently (either using module devices or not) depending on whether the OS supports module devices. I guess the firmware might use the result of _OSI("Module Device") to decide which table to load.