[Devel] Why are empty packages invalid for predefined ACPI objects?

[Devel] Why are empty packages invalid for predefined ACPI objects?

[@ 2010-11-06 15:23 UTC (permalink / raw)]

[-- Attachment #1: Type: text/plain, Size: 585 bytes --]

Hi,

The package validation function AcpiNsCheckPackage() in file nspredef.c
requires that packages be non-empty:

     /* The package must have at least one element, else invalid */

     if (!Count)
     {
         ACPI_WARN_PREDEFINED ((AE_INFO, Data->Pathname, Data->NodeFlags,
             "Return Package has no elements (empty)"));

         return (AE_AML_OPERAND_VALUE);
     }

I don't see, from the ACPI specification, why packages for predefined
ACPI objects must be non-empty.

Where does this requirement come from?

Best regards,

Grégoire Sutre

Re: [Devel] Why are empty packages invalid for predefined ACPI objects?

[Moore, Robert]

[-- Attachment #1: Type: text/plain, Size: 1242 bytes --]

It may not be strictly against the acpi spec, but we'd like to see if this is happening on any platforms.

I'm not sure I can think of a really valid reason why this should happen for the predefined objects.



>-----Original Message-----
>From: devel-bounces(a)acpica.org [mailto:devel-bounces(a)acpica.org] On Behalf
>Of Grégoire Sutre
>Sent: Saturday, November 06, 2010 8:24 AM
>To: devel(a)acpica.org
>Subject: [Devel] Why are empty packages invalid for predefined ACPI
>objects?
>
>Hi,
>
>The package validation function AcpiNsCheckPackage() in file nspredef.c
>requires that packages be non-empty:
>
>     /* The package must have at least one element, else invalid */
>
>     if (!Count)
>     {
>         ACPI_WARN_PREDEFINED ((AE_INFO, Data->Pathname, Data->NodeFlags,
>             "Return Package has no elements (empty)"));
>
>         return (AE_AML_OPERAND_VALUE);
>     }
>
>I don't see, from the ACPI specification, why packages for predefined
>ACPI objects must be non-empty.
>
>Where does this requirement come from?
>
>Best regards,
>
>Grégoire Sutre
>_______________________________________________
>Devel mailing list
>Devel(a)acpica.org
>http://lists.acpica.org/listinfo/devel

Re: [Devel] Why are empty packages invalid for predefined ACPI objects?

[Moore, Robert]

[-- Attachment #1: Type: text/plain, Size: 1778 bytes --]

I'd have to go through the spec, but thinking about it, I'm not sure that any predefined name allows an empty package. All the definitions are either 1) Fixed length package, or 2) Variable length package that is defined as "one or more..."



>-----Original Message-----
>From: Moore, Robert
>Sent: Sunday, November 07, 2010 8:13 PM
>To: 'Grégoire Sutre'; devel(a)acpica.org
>Cc: Lin, Ming M
>Subject: RE: [Devel] Why are empty packages invalid for predefined ACPI
>objects?
>
>It may not be strictly against the acpi spec, but we'd like to see if this
>is happening on any platforms.
>
>I'm not sure I can think of a really valid reason why this should happen
>for the predefined objects.
>
>
>
>>-----Original Message-----
>>From: devel-bounces(a)acpica.org [mailto:devel-bounces(a)acpica.org] On Behalf
>>Of Grégoire Sutre
>>Sent: Saturday, November 06, 2010 8:24 AM
>>To: devel(a)acpica.org
>>Subject: [Devel] Why are empty packages invalid for predefined ACPI
>>objects?
>>
>>Hi,
>>
>>The package validation function AcpiNsCheckPackage() in file nspredef.c
>>requires that packages be non-empty:
>>
>>     /* The package must have at least one element, else invalid */
>>
>>     if (!Count)
>>     {
>>         ACPI_WARN_PREDEFINED ((AE_INFO, Data->Pathname, Data->NodeFlags,
>>             "Return Package has no elements (empty)"));
>>
>>         return (AE_AML_OPERAND_VALUE);
>>     }
>>
>>I don't see, from the ACPI specification, why packages for predefined
>>ACPI objects must be non-empty.
>>
>>Where does this requirement come from?
>>
>>Best regards,
>>
>>Grégoire Sutre
>>_______________________________________________
>>Devel mailing list
>>Devel(a)acpica.org
>>http://lists.acpica.org/listinfo/devel

Re: [Devel] Why are empty packages invalid for predefined ACPI objects?

[@ 2010-11-08 9:54 UTC (permalink / raw)]

[-- Attachment #1: Type: text/plain, Size: 1693 bytes --]

On 11/08/2010 05:23, Moore, Robert wrote:
> I'd have to go through the spec, but thinking about it, I'm not sure that
> any predefined name allows an empty package. All the definitions are
> either 1) Fixed length package, or 2) Variable length package that is
> defined as "one or more..."

The practical example that triggered this question is the method _DOD
(ACPI 4.0a, Appendix B, p. 698). For this method, the return value is:

     "A package containing a variable-length list of Integers, each of
      which contains the 32-bit device attribute of a child device".

As far as I can see, the specification does not require the list to be
non-empty.


On some laptop (see report [1]), the BIOS declares a device as follows:

              Device (VID2)
              {
                  Name (_ADR, 0x00020001)
                  Method (_DOS, 1, NotSerialized)
                  {
                  }


                  Method (_DOD, 0, NotSerialized)
                  {
                      Return (Package (0x00) {})
                  }
              }

The device may appear useless since _DOS does nothing and _DOD returns an
empty package. But VID2 is notified in the rest of the BIOS ASL. Maybe
the methods _DOS and _DOD under VID2 are there to identify VID2 as a display
adapter device?

On this laptop, the _DOD method triggers an ACPICA warning

ACPI Warning for \_SB_.PCI0.VID2._DOD: Return Package has no elements
(empty) (20100528/nspredef-572)

but, since VID2 conforms to the spec (afaics), is this warning really
deserved?

Best regards,

Grégoire

[1] http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=44042

Re: [Devel] Why are empty packages invalid for predefined ACPI objects?

[Moore, Robert]

[-- Attachment #1: Type: text/plain, Size: 2885 bytes --]


>                  Method (_DOD, 0, NotSerialized)
>                  {
>                      Return (Package (0x00) {})
>                  }

Looks odd to me. 

What we are trying to do with the repair code in ACPICA is to move toward a model where ACPICA will guarantee that if AE_OK is returned from the execution of a predefined method, then in fact something useful was returned.

The point here, of course, is to eliminate a lot of code that checks for object types, lengths, etc. from the execution of these methods/names.

In the case above, I don't see that anything useful is returned, and the warning indicates that.

And what we are moving toward is to return an error code in the case above, something like AE_NOT_USEFUL_METHOD or AE_EMPTY_PACKAGE.

Then, the driver can just move on and ignore the results of the method.

Bob

>-----Original Message-----
>From: Grégoire Sutre [mailto:gregoire.sutre(a)gmail.com]
>Sent: Monday, November 08, 2010 1:54 AM
>To: Moore, Robert
>Cc: devel(a)acpica.org; Lin, Ming M
>Subject: Re: [Devel] Why are empty packages invalid for predefined ACPI
>objects?
>
>On 11/08/2010 05:23, Moore, Robert wrote:
>> I'd have to go through the spec, but thinking about it, I'm not sure that
>> any predefined name allows an empty package. All the definitions are
>> either 1) Fixed length package, or 2) Variable length package that is
>> defined as "one or more..."
>
>The practical example that triggered this question is the method _DOD
>(ACPI 4.0a, Appendix B, p. 698). For this method, the return value is:
>
>     "A package containing a variable-length list of Integers, each of
>      which contains the 32-bit device attribute of a child device".
>
>As far as I can see, the specification does not require the list to be
>non-empty.
>
>
>On some laptop (see report [1]), the BIOS declares a device as follows:
>
>              Device (VID2)
>              {
>                  Name (_ADR, 0x00020001)
>                  Method (_DOS, 1, NotSerialized)
>                  {
>                  }
>
>
>                  Method (_DOD, 0, NotSerialized)
>                  {
>                      Return (Package (0x00) {})
>                  }
>              }
>
>The device may appear useless since _DOS does nothing and _DOD returns an
>empty package. But VID2 is notified in the rest of the BIOS ASL. Maybe
>the methods _DOS and _DOD under VID2 are there to identify VID2 as a
>display
>adapter device?
>
>On this laptop, the _DOD method triggers an ACPICA warning
>
>ACPI Warning for \_SB_.PCI0.VID2._DOD: Return Package has no elements
>(empty) (20100528/nspredef-572)
>
>but, since VID2 conforms to the spec (afaics), is this warning really
>deserved?
>
>Best regards,
>
>Grégoire
>
>[1] http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=44042