AML: Handle NullName in NameString

[alnyan]

ACPI 6.2, section 20.2.2 defines NameString as follows:

NameString := <RootChar NamePath> | <PrefixPath NamePath>
PrefixPath := Nothing | <'^' PrefixPath>
NamePath := NameSeg | DualNamePath | MultiNamePath | NullName 

In the name_string() parser, there currently is a check for an empty NamePath throwing an error if the length of the path parsed by name_path() is zero, which prevents the parser from handling NullNames properly.

[alnyan]

I'm not fully sure, but it seems that null names just represent the root scope path

[alnyan]

The problem seems to be caused by a quirk in an real device (Thinkpad E14 Gen2 SSDT3) AML and is not a part of any actual SuperName, decompiled AML shows the following:

DefinitionBlock ("", "SSDT", 1, "LENOVO", "STD3", 0x00000001)
{
    // ...

    Scope (\_SB)
    {
        Name (D0S0, 0x01)
        Name (D3S0, 0x01)
        Name (D0S1, 0x01)
        Name (D3S1, 0x01)
        Name (STDS, Zero)
        Zero

        PowerResource (P0S0, 0x00, 0x0000) 
        {
            // ...
        }

        // ...
    }

    // ...
}

As it turned out, there was a weird ZeroOp inside the _SB scope, which the parser tried to interpret as some kind of name. Adding a ZeroOp handler at the start of named_obj()'s choice! macro resolves the issue, though I'm not quite sure this is the correct fix to that, as the ACPI specification doesn't say anything about ZeroOps appearing as NamedObjs.

UPD: The same weird op is also present in the decompiled AML of the same thinkpad's SSDT11 (this time it's a OneOp):

DefinitionBlock ("", "SSDT", 1, "LENOVO", "TP-R1A  ", 0x00000001)
{
    // ...
    Name (M278, 0x01)
    Name (M279, 0x01)
    Name (M27A, 0x01)
    Name (APGE, Zero)
    One
    Name (ACGE, 0x01)
    // ...
}

[konradybcio]

FWIW it looks like such weird ZeroOps are present in all Qualcomm ACPI tables.. See https://github.com/aarch64-laptops/build/blob/master/misc/microsoft-devkit-2023/DSDT.dsl for an example (there's a .dat (.aml) in that directory too)

[konradybcio]

iasl unceremoniously errors out when trying to parse these, I was told ms asl consumes them fine.. which is supposedly what the aforementioned tables are compiled with