Re: PROBLEM: Calling ObjectType on buffer field reports type integer

Maximilian Luz <luzmaximilian@xxxxxxxxx> · Sat, 23 Nov 2019 00:00:34 +0100

On 11/22/19 11:07 PM, Moore, Robert wrote:
I'm not seeing this problem. For example:
     Method (DS01)
     {
         Name(BUFZ, Buffer(48){})
         CreateField(BUFZ, 192, 69, DST0)
         Store (ObjectType (DST0), Debug)
     }

Acpiexec dsdt.aml
Eval DS01
Evaluating \DS01
ACPI Debug:  0x000000000000000E

0x0E is in fact type "buffer field".

Hi,

unfortunately, the bug is a bit more convoluted, here's a minimal
example:

    Method (DS01)
    {
        Name(BUFZ, Buffer(48){})
        CreateField(BUFZ, 192, 32, DST0)
        Local0 = DST0
        Store (ObjectType (Local0), Debug)
    }

It is based on the combination of CreateField with length smaller or
equal to the maximum integer size and the assignment of the field to a
local variable. For me, this yields

Eval DS01
Evaluating \DS01
ACPI Debug:  0x0000000000000001

As already iterated, this should be the correct behavior according to
spec, but causes failures on Microsoft Surface devices.

For reference, I've added two links to the relevant parts in the DSDT of
the MS Surface Book 2: In short, MS identifies errors by the type of a
local variable which is supposed to either contain a payload (buffer) or
an error value (integer). This local variable (Local4) is previously
assigned from a buffer field [1] containing some payload data. However
on Linux, if the payload data is smaller than or equal to 64 bits, the
type of the variable is integer and the transaction gets misidentified
as having failed [2].

[1]: https://github.com/qzed/surfacebook2-dsdt/blob/fa0ca7c7cba8fb0da1e79c282f9a9f4a12eaaa17/dsdt.dsl#L15396-L15397
[2]: https://github.com/qzed/surfacebook2-dsdt/blob/fa0ca7c7cba8fb0da1e79c282f9a9f4a12eaaa17/dsdt.dsl#L15427

In hindsight, the subject line is not describing the actual problem very
well, I apologize for that.

Thanks,
Maximilian