Adding Guy to the list > -----Original Message----- > From: linux-acpi-owner@xxxxxxxxxxxxxxx [mailto:linux-acpi- > owner@xxxxxxxxxxxxxxx] On Behalf Of Bjorn Helgaas > Sent: Friday, April 21, 2006 11:22 AM > To: Moore, Robert > Cc: Kenji Kaneshige; Brown, Len; linux-acpi@xxxxxxxxxxxxxxx; Andrew > Morton; Keshavamurthy, Anil S; Keiichiro Tokunaga; Motoyuki Ito > Subject: Re: [2/2] ACPI: report "Module Device" support via _OSI > > On Friday 21 April 2006 11:23, Moore, Robert wrote: > > Response from Guy Therien: > > > > When the module device is ignored the devices under it will not be > > enumerated and so those devices need to be declared elsewhere where they > > will be enumerated in the event that the OS does not support module > > device. > > > > Consider processors on hot plug modules that are not unpluggable on some > > OS. They need to be in the \_SB scope. If OS supports module device then > > they need to be under the module so the module can be ejected. They > > CANNOT be in 2 places at the same time. > > I'm with you so far. Does that have a bearing on what _OSI("Module > Device") should return if there is a container module, but it isn't > loaded? > > My theory is that if there is a container module, _OSI should return > true even if the module isn't loaded. The firmware can then place > the CPUs under the module device, and the OS will enumerate the CPUs > when the container driver is loaded. > > This means CPUs will probably be discovered later than they are today. > Is there a problem with that? > > > > -----Original Message----- > > > From: Kenji Kaneshige [mailto:kaneshige.kenji@xxxxxxxxxxxxxx] > > > Sent: Thursday, April 20, 2006 1:33 AM > > > To: Bjorn Helgaas > > > Cc: Brown, Len; linux-acpi@xxxxxxxxxxxxxxx; Andrew Morton; Moore, > > Robert; > > > Keshavamurthy, Anil S; Keiichiro Tokunaga; Motoyuki Ito > > > Subject: Re: [2/2] ACPI: report "Module Device" support via _OSI > > > > > > Bjorn Helgaas wrote: > > > > On Wednesday 19 April 2006 00:34, Kenji Kaneshige wrote: > > > > > > > >>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.) > > > > > > > > > > > > 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. > > > > > > > > > > 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 > > > > > > > > > > > > > >>Bjorn Helgaas wrote: > > > >> > > > >>>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. > > > >>> > > > >>>Signed-off-by: Bjorn Helgaas <bjorn.helgaas@xxxxxx> > > > >>> > > > >>>Index: work-mm5/drivers/acpi/utilities/uteval.c > > > >>>=================================================================== > > > >>>--- work-mm5.orig/drivers/acpi/utilities/uteval.c 2006-04-18 > > > 15:31:22.000000000 -0600 > > > >>>+++ work-mm5/drivers/acpi/utilities/uteval.c 2006-04-18 > > > 15:32:38.000000000 -0600 > > > >>>@@ -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 majordomo@xxxxxxxxxxxxxxx > > > >>>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 majordomo@xxxxxxxxxxxxxxx > > > >>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 majordomo@xxxxxxxxxxxxxxx > 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
