Re: [PATCH] ACPI / EC: handle ECDT EC and DSDT EC simultaneously

["Rafael J. Wysocki" <rjw@rjwysocki.net>]

On Thursday, April 27, 2017 03:18:04 AM Zheng, Lv wrote:
> Hi,
> 
> > From: Daniel Drake [mailto:drake@endlessm.com]
> > Subject: Re: [PATCH] ACPI / EC: handle ECDT EC and DSDT EC simultaneously
> > 
> > Hi Lv,
> > 
> > Thanks for the detailed response. In trying to decode the tricky code
> > flow and seeing all this first_ec / boot_ec / DSDT EC / ECDT EC stuff,
> > I seem to have made the wrong interpretation about how this is
> > designed.
> > 
> > On Sun, Apr 23, 2017 at 10:43 PM, Zheng, Lv <lv.zheng@intel.com> wrote:
> > > The entire problem looks to me is:
> > > When GPE setting differs between ECDT and DSDT, which one should be
> > > trusted by OS?
> > 
> > This case suggests that Windows uses the ECDT setting, right?
> 
> I checked the provided acpi tables.
> Indeed, the ECDT EC is correct.
> [000h 0000   4]                    Signature : "ECDT"    [Embedded Controller Boot Resources Table]
> [004h 0004   4]                 Table Length : 000000C1
> [008h 0008   1]                     Revision : 01
> [009h 0009   1]                     Checksum : EC
> [00Ah 0010   6]                       Oem ID : "_ASUS_"
> [010h 0016   8]                 Oem Table ID : "Notebook"
> [018h 0024   4]                 Oem Revision : 01072009
> [01Ch 0028   4]              Asl Compiler ID : "AMI."
> [020h 0032   4]        Asl Compiler Revision : 00000005
> 
> 
> [024h 0036  12]      Command/Status Register : [Generic Address Structure]
> [024h 0036   1]                     Space ID : 01 [SystemIO]
> [025h 0037   1]                    Bit Width : 08
> [026h 0038   1]                   Bit Offset : 00
> [027h 0039   1]         Encoded Access Width : 00 [Undefined/Legacy]
> [028h 0040   8]                      Address : 0000000000000066
> 
> [030h 0048  12]                Data Register : [Generic Address Structure]
> [030h 0048   1]                     Space ID : 01 [SystemIO]
> [031h 0049   1]                    Bit Width : 08
> [032h 0050   1]                   Bit Offset : 00
> [033h 0051   1]         Encoded Access Width : 00 [Undefined/Legacy]
> [034h 0052   8]                      Address : 0000000000000062
> 
> [03Ch 0060   4]                          UID : 00000000
> [040h 0064   1]                   GPE Number : 23
> [041h 0065  19]                     Namepath : "\_SB.PCI0.LPCB.EC0"
> 
> While the DSDT EC is in fact invalid as it returns 0 from its _STA:
>     Scope (_SB.PCI0.LPCB)
>     {
>         Device (H_EC)
>         {
>             Name (_HID, EisaId ("PNP0C09") /* Embedded Controller Device */)  // _HID: Hardware ID
>             Name (_UID, One)  // _UID: Unique ID
>             Method (_STA, 0, NotSerialized)  // _STA: Status
>             {
>                 ^^^GFX0.CLID = 0x03
>                 Return (Zero)
>             }
>             ...
>         }
>     }
> 
> It doesn't contain _CRS, so it's likely that it will fail in
> acpi_ec_dsdt_probe() due to failure of walk _CRS.
> 
> Are you sure the same problem can be seen no this platform?
> 
> If so, possibly you only need to add some sanity checks in
> acpi_ec_dsdt_probe().

Can you suggest a patch, please?

Ideally, something that can be tested?

Thanks,
Rafael