Created attachment 188532 [details] Patch that adds call to bus_set_resource() for fixed I/O port ranges that wrongly have been defined as relocatable ones The MacBook Pro 11,3's (and possibly other versions') BIOS has a buggy _CRS entry[0]. It is defined as a relocatable I/O range, although its actually a fixed one. This bug currently prevents drivers from allocating the device's resources, since the function acpi_res_set_iorange() in sys/dev/acpica/acpi_resource.c just prints the message: "I/O range not supported". The attached patch adds a call to bus_set_resource(), if range_min + length == range_max, which should be an indication that the BIOS is buggy and the resource is actually a fixed I/O range. Additionally, a warning message is printed if the system boots in verbose mode, since the _CRS should not contain resource definitions like these. This was suggested by John Baldwin [1]. [0] The device's _CRS as returned by acpidump -td: Device (GMUX) { ... Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings { IO (Decode16, 0x0700, // Range Minimum 0x07FF, // Range Maximum 0x01, // Alignment 0xFF, // Length ) }) ... } [1] https://lists.freebsd.org/pipermail/freebsd-hackers/2017-November/051744.html
This patch looks good to me though I may not get around to committing it for a few days.
A commit references this bug: Author: jhb Date: Wed Apr 18 18:36:26 UTC 2018 New revision: 332733 URL: https://svnweb.freebsd.org/changeset/base/332733 Log: Workaround fixed I/O port resources encoded as I/O port ranges in _CRS. ACPI I/O port descriptors use _MIN and _MAX fields to specify the set of allowable base (start) addresses for an I/O port resource along with a _LEN field specifying the length. A fixed resource is supposed to be encoded with _MIN == _MAX, but some buggy firmwares instead set _MAX to the end of the fixed range. Relocating I/O ranges only make sense in _PRS (possible resource settings), not in _CRS (current resource settings), so if an I/O port range with _MAX set set to the end of the range is present in _CRS, treat it as a fixed I/O port resource starting at _MIN. PR: 224096 Submitted by: Harald B?hm <harald@boehm.codes> Pointy hat to: jhb (taking so long to actually commit this) MFC after: 1 week Changes: head/sys/dev/acpica/acpi_resource.c
Sorry for taking so long to committing this. I've merged it in with a few minor tweaks. Thanks!
(In reply to John Baldwin from comment #3) Thanks for committing it! I was able to verfiy that the patch has the desired effect. My driver is able to allocate the device's resources. Here is the relevant line from dmesg: agx0: <Apple Inc. Graphics Multiplexer> port 0x700-0x7fe on acpi0
A commit references this bug: Author: jhb Date: Sat Apr 28 00:16:55 UTC 2018 New revision: 333080 URL: https://svnweb.freebsd.org/changeset/base/333080 Log: MFC 332733: Workaround fixed I/O port resources encoded as I/O port ranges in _CRS. ACPI I/O port descriptors use _MIN and _MAX fields to specify the set of allowable base (start) addresses for an I/O port resource along with a _LEN field specifying the length. A fixed resource is supposed to be encoded with _MIN == _MAX, but some buggy firmwares instead set _MAX to the end of the fixed range. Relocating I/O ranges only make sense in _PRS (possible resource settings), not in _CRS (current resource settings), so if an I/O port range with _MAX set set to the end of the range is present in _CRS, treat it as a fixed I/O port resource starting at _MIN. PR: 224096 Changes: _U stable/10/ stable/10/sys/dev/acpica/acpi_resource.c _U stable/11/ stable/11/sys/dev/acpica/acpi_resource.c