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

["Zheng, Lv" <lv.zheng@intel.com>]

Hi,

> From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-owner@vger.kernel.org] On Behalf Of Daniel
> Drake
> Subject: Re: [PATCH] ACPI / EC: handle ECDT EC and DSDT EC simultaneously
> 
> Hi,
> 
> On Fri, Apr 28, 2017 at 12:33 AM, Zheng, Lv <lv.zheng@intel.com> 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

Yes, there are 2 ECs.
        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)
            }

        Device (EC0)
        {
            Name (_HID, EisaId ("PNP0C09") /* Embedded Controller Device */)  // _HID: Hardware ID
            Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
            {
                IO (Decode16,
                    0x0062,             // Range Minimum
                    0x0062,             // Range Maximum
                    0x00,               // Alignment
                    0x01,               // Length
                    )
                IO (Decode16,
                    0x0066,             // Range Minimum
                    0x0066,             // Range Maximum
                    0x00,               // Alignment
                    0x01,               // Length
                    )
            })
            Method (_GPE, 0, NotSerialized)  // _GPE: General Purpose Events
            {
                Local0 = 0x33
                Return (Local0)
            }

And linux EC driver only tries the 1st one.
You probably should add sanity check to skip first one, and return the 2nd one.

Thanks
Lv

> 
> Daniel
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html