On Thursday, April 27, 2017 03:18:04 AM Zheng, Lv wrote: > Hi, > > > From: Daniel Drake [mailto:drake@xxxxxxxxxxxx] > > 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@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
