On Fri, 14 Oct 2016, Ilya Kaliman wrote:
> dmesg:
> OpenBSD 6.0 (GENERIC.MP) #1: Thu Sep  8 16:32:34 PDT 2016
>     i...@puffy.my.domain:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> acpiec0 at acpi0: Failed to read resource settings
> acpidump:

I've taken a brief look at this.  The definition of the resources for the 
embedded controller is odd:

    Scope (_SB.PCI0.LPCB)
        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
                IO (Decode16,
                    0x0068,             // Range Minimum
                    0x0068,             // Range Maximum
                    0x01,               // Alignment
                    0x08,               // Length
                Memory32Fixed (ReadWrite,
                    0xFE800E00,         // Address Base
                    0x00010000,         // Address Length

Note that there are *four* resources...but even revision 6.1 of the ACPI 
standard only gives meaning for the first *three*, and the third resource 
is the GPIO for the SCI interrupt...but is only for hardware-reduced ACPI 
platforms, which this machine is not:
     Use APIC Physical Destination Mode (V4) : 0
                       Hardware Reduced (V5) : 0
                      Low Power S0 Idle (V5) : 0

So I guess there's two defects in acpicec.c right now:
 - we don't use a third resource for the SCI interrupt when hw-reduced
 - we barf on extra resources despite vendors deciding to throwing them 
   in for the hell of it

Perhaps acpiec should use aml_parse_resource() instead of the hand-crafted 
parsing it does right now?  That would solve the second problem, at 

Until we have a better fix, simply deleting the end-of-buffer check as 
you've done should have the same end effect, but expect a diff to try out 
at some point here...

Philip Guenther

Reply via email to