Inconsistency between AML and specification:Unexpected types

[Aerath]

One of my computers, an Ideapad 15IKB-80TV, has a DSDT that seems to contain ACPI object types in structures that should contain other types.

Small excerpt from it's DSDT (disassembled with official iasl):

Code: Select all

Device(PCI0)
{
    Name(...)
    Name(...)
    Method(...)
    ....
}
...
If ((ECR1 == One))
// Encoded as: A0 40 07 93 45 43 52 31 01
// Which translates to: If PkgLen(0x70) LEqual "ECR1" 1

So here we have a Method where I was expecting an Object.
Also, what looks like a NameSeg in a NamePath in a NameString, where I was expecting a TermArg.
From the ACPI specification 5.0A section 20 :

Code: Select all

// 20.2.3 Data Objects Encoding
DataRefObject := DataObject | ObjectReference | DDBHandle
// 20.2.5 Term Objects Encoding
ObjectList           := Nothing | <Object ObjectList>
Object               := NameSpaceModifierObj | NamedObj
// 20.2.5.1 Namespace Modifier Objects Encoding
NameSpaceModifierObj := DefAlias | DefName | DefScope
// 20.2.5.2 Named Objects Encoding
NamedObj        := DefBankField | DefCreateBitField | DefCreateByteField | DefCreateDWordField |
                   DefCreateField | DefCreateQWordField |DefCreateWordField | DefDataRegion | 
                   DefOpRegion | DefPowerRes | DefProcessor | DefThermalZone
DefDevice := DeviceOp PkgLength NameString ObjectList
// 20.2.5.3 Type 1 Opcodes Encoding
DDBHandleObject := SuperName

Nowhere there is a possibility for a DefMethod. In fact DefMethod is not part of any rule other than it's definition in section 20.2.5.2 (there are others structures that are defined but never used).
Since DefMethod is defined in a section entitled "Named Object", I assumed that it was a possible variant of NamedObj.
However, as I found more and more unexpected structs, I started to wonder if either Lenovo made a really weird DSDT or if I was completely wrong and not understanding the ACPI specification.
I tend to think I'm always the one in cause, but the specification seems rather inconsistent (DDBHandle used in DataRefObject but never defined, while there is a DDBHandleObject. There are a handful of things like this).

Did anybody face the same problem ?

[MollenOS]

Could it help examining ACPICA to see how they handle these inconsistensies?

[jnc100]

The examples you have provided are consistent with the spec.

Methods can be defined within Device. Indeed, the ASL example for Device in the spec does just this. I think, however, there is a problem with the spec you are quoting as the AML reference that I have (spec ver 4.0a) has the following for NamedObj:

Code: Select all

NamedObj	:= DefBankField | DefCreateBitField | DefCreateByteField |
        DefCreateDWordField | DefCreateField | DefCreateQWordField |
        DefCreateWordField | DefDataRegion | DefDevice | DefEvent |
        DefField | DefIndexField | DefMethod | DefMutex | DefOpRegion |
        DefPowerRes | DefProcessor | DefThermalZone

which includes DefDevice.

For your second example, what you see is a NameSeg, which is also a NamePath, a NameString, a UserTermObj, a Type2Opcode and therefore a TermArg.

If that does not appear obvious from the specification you have, perhaps try a different version as yours may have errors. I have managed to make a resonably complete AML interpreter from the 4.0a version.

Thanks,
John.