Hi, On Fri, Apr 28, 2017 at 12:33 AM, Zheng, Lv <lv.zheng@xxxxxxxxx> wrote: > However in the above debugging commit, I'm sure we shouldn't invoke _STA in ec_parse_device(). > As the reasons below. > > In theory, using DSDT EC as boot EC is not spec compliant. > It's just a workaround in Linux for not knowing the Windows device enumeration orders. > Especially, the order of executing the control method execution that may contain hardware initialization code. > Such control methods are mostly _STA/_INI. > While for _HID/_CRS/_GPE/_BBN, it is unlikely to trigger order issues and it might be safe to invoke them such early. > > If you executes _STA here, you might bring EC._STA execution prior than other _INI/_STA and may break some other platforms. > So for now, I think you should only add simple sanity checks for ioports. > And since you have the direct accesses to these affected platforms, you can help to provide such working sanity check improvements for us. In the DSDT you were looking at the H_EC device, but for whatever reason, there are two ECs in this DSDT and the one that Linux picks up is the 2nd one, \_SB_.PCI0.LPCB.EC0. This device has no _STA but does have valid _CRS, and the debug patch results agree: ACPI : EC: acpi_ec_dsdt_probe: search for DSDT EC ACPI : EC: ec_parse_device: _STA status 5 val 0 ACPI : EC: ec_parse_device: _CRS status 0 command 66 data 62 ACPI : EC: EC stopped ACPI : EC: EC started ACPI: \_SB_.PCI0.LPCB.EC0_: Used as first EC acpidump output is at https://www.dropbox.com/s/d3w2xrmrz1oklnw/x580vd_acpi.tgz?dl=0 Daniel -- 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
