Bug 5322

Created attachment 6172 [details]
Workaround for acpica

Add an object to the current scope if a Z00X object is used that has not yet
declared.

Created attachment 6173 [details]
Same workaround patched against 2.6.14-rc1

Kernel tested with a (not disassembled/recompiled) broken DSDT. 
One warning is printed at early DSDT parse time for undefined Z00X workaround. 
Battery state works fine now. 

please attach the acpidump output

Created attachment 6174 [details]
acpidmp of a affected machine - grep for Z00G

// Workaround for undefined Z00X objects that seem to be predefined
// numbers in other compilers/interpreters.

Is this really true, or do "other" compilers/interpreters simply ignore 
unresolved names in some cases? What would be the point of having such 
predefined numbers, and why would anybody use "Z007" instead of the number 
they really wanted? Seems cryptic to me.

I find that the "other" compiler will compile even this code:

 Name (PBSS, Package () 
            { 
                0x00, 
                XXXX, 
                YYYY, 
                Z00G,
                _SB_.ABCD,
                jfds.jhss.ssss,
                0x2710 
            }) 

It would appear that virtually any ACPI name will work, the name is not 
checked for existence.  Therefore, a more general workaround will be required, 
not simply a check for names of the form Z00?

Actually, this is more of an ASL grammar change, I think. These names are not 
being treated as full references, they are just being treated as strings 
(albeit strings that represent a syntactically correct ACPI pathname.)

So we need an empty initialised string placeholder in package member
declarations if the name is not found in namespace?
I searched a bit to only add a new node/object if it is a package member
delaration, but I gave up ...
So in general the fix is right, but should only get triggered if it is a package
member declaration and if, we could add a placeholder for every not already
declared object (not only Z00X)?
I have to give the machine back in a week or so. I still have another bugreport,
but this would be more effort to test.

Why is this set to needinfo -> by mistake? 
Will this issue be addressed?  
I could have a look at it, with acpiexec it should be possible to test in 
userspace ... 
The ACPIspec says that external methods (and other variables, e.g. Field 
members?) can be referenced. Unfortunately only examples of declarations inside 
the Package itself are made. 
So we have a problem here similar to the not correctly referenced Alias problem 
if the declaration of the referenced Package member comes after the Package 
declaration, does this already work? 
E.g.: 
Package(){FIEA, FIEB,META, METB, ...} 
after that comes: 
Field (....) {FIEA, FIEB, ...} 
Method META (...) {} 
Method METB (...) {} 
Is that possible and should it work? 
 
Additionally allow unreferenced/uninitialised objects we need something like: 
 1) Check whether the Package member is a reference, if not put it into a list  
    of unreferenced Package members 
 2) After parsing everything, check all unreferenced Package members and search  
    whether the object now exists and has been declared after the Package  
    declaration. 
 3) If it does exist -> create the link/reference. 
 4) If it does not exist (as it is the case for these Z00x declarations) add an  
    uninitialised buffer/string object to the Package. 
 
This is more complex as I thought... as said I can have a look, but maybe this 
is a bit too complex for me... 

This is on my list of things to do. We are thinking of allowing unresolved 
references in limited contexts (in the AML interpreter). It will probably take 
some time, as your analysis suggests. Currently, names are resolved very early 
in the parsing process, and there is very little context at that time as to 
what the name will be used for.

As far as forward references -- in general, these work properly, as multiple 
passes are made through tables and control methods to resolve these. The 
problem with forward references to Aliases is a specific bug, not a general 
problem with the multipass mechanism.

*** Bug 5588 has been marked as a duplicate of this bug. ***

A fix for this has been released in version 20051216:

Implemented optional support to allow unresolved names within ASL Package 
objects. A null object is inserted in the package when a named reference 
cannot be located in the current namespace. Enabled via the interpreter slack 
flag, this should eliminate AE_NOT_FOUND exceptions seen on machines that 
contain such code.

ACPICA 20050127 shipped in Linux-2.6.16-rc1-git6 -- closing.

20060127 that is