From owner-freebsd-hackers@freebsd.org Wed Nov 22 19:47:14 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7319BDF3CDF for ; Wed, 22 Nov 2017 19:47:14 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4B74266B77 for ; Wed, 22 Nov 2017 19:47:14 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by mail.baldwin.cx (Postfix) with ESMTPSA id DE50C10A8BA; Wed, 22 Nov 2017 14:47:12 -0500 (EST) From: John Baldwin To: freebsd-hackers@freebsd.org Cc: Harald =?ISO-8859-1?Q?B=F6hm?= Subject: Re: ACPICA missing support for device I/O port ranges Date: Tue, 21 Nov 2017 15:38:30 -0800 Message-ID: <2497671.hb7Q7Esj6H@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.1-STABLE; KDE/4.14.30; amd64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Wed, 22 Nov 2017 14:47:13 -0500 (EST) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Nov 2017 19:47:14 -0000 On Saturday, November 18, 2017 06:52:54 PM Harald B=F6hm wrote: > Hi all, >=20 > I've been working on a device driver lately and was having trouble > allocating its resources using bus_alloc_resource_any(), although its= > I/O ports can be read from its _CRS. >=20 > This is the output of acpidump -td: >=20 > Device (GMUX) > { > ... > Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settin= gs > { > IO (Decode16, > 0x0700, // Range Minimum > 0x07FF, // Range Maximum > 0x01, // Alignment > 0xFF, // Length > ) > }) > ... > } >=20 > After digging into the code in /sys/dev/acpica/acpi_resources.c I was= > able to find the problem. The function acpi_res_set_iorange(), which > seems to be responsible for calling bus_set_resource() is just a > function stub that prints a message that I/O ranges are not supported= . >=20 > static void > acpi_res_set_iorange(device_t dev, void *context, uint64_t low, > =09=09 uint64_t high, uint64_t length, uint64_t align) > { > struct acpi_res_context=09*cp =3D (struct acpi_res_context *)cont= ext; >=20 > if (cp =3D=3D NULL) > =09return; > device_printf(dev, "I/O range not supported\n"); > } >=20 > After adding a call to bus_set_resource() to that function, I was abl= e > to allocate the device's resources. >=20 > Does anyone know, why the function has not been implemented or why I/= O > ranges are not supported? IO ranges are not supposed to be in _CRS. An IO range is used for relo= catable resources and would be in _PRS to say "you can use I/O ports at address= es, A, B, or C". Specifically, the "Range" of an I/O port is the range of the= starting addresses. Normal I/O addresses in _CRS are set to a fixed ra= nge with the same values for Range Min and Range Max. For example: IO (Decode16, 0x0CF8, // Range Minimum 0x0CF8, // Range Maximum 0x01, // Alignment 0x08, // Length ) This says it uses the '8' (Length) I/O ports starting at 0xcf8 and that= they are fixed at 0xcf8 because the starting address has to be >=3D 0xcf8 (r= ange min) and <=3D 0xcf8 (range max). The _CRS blob from your dump says that it = wants to allocate 255 I/O ports with a starting address of 0x700, 0x701, 0x702, = 0x703, .... , 0x7fd, 0x7fe, or 0x7ff, but it doesn't tell us _which_ of those = ranges it is actually using (e.g. is it using 0x700 -> 0x7ff or is it using 0x= 780 -> 0x88f, etc.). Probably it's just a bug in your BIOS and it means to us= e 0x700 -> 0x7ff and the BIOS author doesn't understand what Range Maximu= m means. It is not the end address of the full I/O port addresses reserved, but = the maximum starting address (I agree this is a bit odd, but this is what t= he spec says). Assuming the BIOS is buggy, we can add a hack for iorange that adds the= resource if max =3D=3D min + length and emit a warning under bootverbos= e about the BIOS being buggy. --=20 John Baldwin