[2/2] ACPI: report "Module Device" support via _OSI

[2/2] ACPI: report "Module Device" support via _OSI

[Bjorn Helgaas]

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@hp.com>

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 */

Re: [2/2] ACPI: report "Module Device" support via _OSI

[Kenji Kaneshige]

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


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@hp.com>
> 
> 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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [2/2] ACPI: report "Module Device" support via _OSI

[Bjorn Helgaas]

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.

> 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@hp.com>
> > 
> > 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@vger.kernel.org
> > 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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [2/2] ACPI: report "Module Device" support via _OSI

[Kenji Kaneshige]

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@hp.com>
>>>
>>>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@vger.kernel.org
>>>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@vger.kernel.org
>>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
> 
> 

Re: [2/2] ACPI: report "Module Device" support via _OSI

[Bjorn Helgaas]

On Thursday 20 April 2006 02:33, Kenji Kaneshige wrote:
> 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"...

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.

RE: [2/2] ACPI: report "Module Device" support via _OSI

[Moore, Robert]

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.



> -----Original Message-----
> From: Kenji Kaneshige [mailto:kaneshige.kenji@jp.fujitsu.com]
> Sent: Thursday, April 20, 2006 1:33 AM
> To: Bjorn Helgaas
> Cc: Brown, Len; linux-acpi@vger.kernel.org; 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@hp.com>
> >>>
> >>>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@vger.kernel.org
> >>>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@vger.kernel.org
> >>More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >>
> >
> >

Re: [2/2] ACPI: report "Module Device" support via _OSI

[Bjorn Helgaas]

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@jp.fujitsu.com]
> > Sent: Thursday, April 20, 2006 1:33 AM
> > To: Bjorn Helgaas
> > Cc: Brown, Len; linux-acpi@vger.kernel.org; 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@hp.com>
> > >>>
> > >>>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@vger.kernel.org
> > >>>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@vger.kernel.org
> > >>More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > >>
> > >
> > >
> 

RE: [2/2] ACPI: report "Module Device" support via _OSI

[Moore, Robert]

Adding Guy to the list


> -----Original Message-----
> From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
> owner@vger.kernel.org] On Behalf Of Bjorn Helgaas
> Sent: Friday, April 21, 2006 11:22 AM
> To: Moore, Robert
> Cc: Kenji Kaneshige; Brown, Len; linux-acpi@vger.kernel.org; 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@jp.fujitsu.com]
> > > Sent: Thursday, April 20, 2006 1:33 AM
> > > To: Bjorn Helgaas
> > > Cc: Brown, Len; linux-acpi@vger.kernel.org; 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@hp.com>
> > > >>>
> > > >>>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@vger.kernel.org
> > > >>>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@vger.kernel.org
> > > >>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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [2/2] ACPI: report "Module Device" support via _OSI

[Therien, Guy]

Bjorn's response to my statements is correct.
The idea is that _OSI tells the platform that the OS supports the
loading of a module device so the platform firmware can declare devices
under it instead of somewhere else. i.e. the platform can assume that
the devices will be loaded. 
I view it as a AMLI configuration interface - Does your ACPI
implementation support module devices? AMLI needs to know the general
answer - can a module device driver be loaded.
Guy

-----Original Message-----
From: Moore, Robert 
Sent: Friday, April 21, 2006 11:25 AM
To: Bjorn Helgaas
Cc: Kenji Kaneshige; Brown, Len; linux-acpi@vger.kernel.org; Andrew
Morton; Keshavamurthy, Anil S; Keiichiro Tokunaga; Motoyuki Ito;
Therien, Guy
Subject: RE: [2/2] ACPI: report "Module Device" support via _OSI

Adding Guy to the list


> -----Original Message-----
> From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi- 
> owner@vger.kernel.org] On Behalf Of Bjorn Helgaas
> Sent: Friday, April 21, 2006 11:22 AM
> To: Moore, Robert
> Cc: Kenji Kaneshige; Brown, Len; linux-acpi@vger.kernel.org; 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@jp.fujitsu.com]
> > > Sent: Thursday, April 20, 2006 1:33 AM
> > > To: Bjorn Helgaas
> > > Cc: Brown, Len; linux-acpi@vger.kernel.org; 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@hp.com>
> > > >>>
> > > >>>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@vger.kernel.org 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@vger.kernel.org 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@vger.kernel.org More majordomo 
> info at  http://vger.kernel.org/majordomo-info.html