[Bug 264414] ACPI resource allocation for buggy _CRS entries causes "I/O range not supported" message

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264414

            Bug ID: 264414
           Summary: ACPI resource allocation for buggy _CRS entries causes
                    "I/O range not supported" message
           Product: Base System
           Version: 13.1-STABLE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: kern
          Assignee: bugs@FreeBSD.org
          Reporter: crahman@gmail.com

There's detailed background information regarding this in bug #224096.

With the MacBook Pro in bug #224096, the range's maximum - minimum was equal to
the specified length.

But in the AMI 'Alaska' BIOS, the maximum is selected so that the length
includes both the top and bottom bytes, e.g. maximum - minimum  + 1:

                IO (Decode16,
                    0x0070,             // Range Minimum
                    0x0077,             // Range Maximum
                    0x01,               // Alignment
                    0x08,               // Length
                    )

And so, as a result, the "I/O range not supported" message is generated and no
resource is allocated.

This is in a ResourceTemplate for the _CRS for PCI0.

An sample ASL from the AMI 'Alaska' BIOS that illustrates the issue may be
found here: 

https://github.com/linuxhw/ACPI/blob/master/Desktop/TONK/TN/TN1402/ABC6298CB633

I haven't noticed any malfunctions resulting from this other than the error
message, and correcting either the ASL or changing acpi_resource.c to set up
the resource anyway does not change this.  I also don't know enough about how
the PCI controller uses this range to know if there should be a problem.  

However, it appears that perhaps the correct solution to bug #224096 might be
not to check for both (high == (low + length)) and (high == (low + length -
1)), but rather to just set up the resource anyway, perhaps making note of the
compensation for the BIOS problem.

As this is hardly a new problem, and no one has reported any malfunctions
resulting from it, the issue is not so much this particular case but to provide
a reference for some future troubleshooter's search.

My incomplete understanding of the situation means I am only suggesting that
someone who knows more about this examine the issue.

-- 
You are receiving this mail because:
You are the assignee for the bug.