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
