From owner-freebsd-hackers@freebsd.org Mon Dec 4 21:28:20 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 CB811E6B38D for ; Mon, 4 Dec 2017 21:28:20 +0000 (UTC) (envelope-from harald.boehm@fau.de) Received: from mx-rz-1.rrze.uni-erlangen.de (mx-rz-1.rrze.uni-erlangen.de [IPv6:2001:638:a000:1025::14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 773A57A327 for ; Mon, 4 Dec 2017 21:28:20 +0000 (UTC) (envelope-from harald.boehm@fau.de) Received: from mx-rz-1.rrze.uni-erlangen.de (mx-rz-1.rrze.uni-erlangen.de [IPv6:2001:638:a000:1025::14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx-rz-1.rrze.uni-erlangen.de (Postfix) with ESMTPS id 3yrHzj4Pltz8t6Y for ; Mon, 4 Dec 2017 22:28:17 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fau.de; s=fau-2013; t=1512422897; bh=d1xDrSO5l3zx9U9QLW91iMXdUaAc6YYqJVqwR5tK/EM=; h=Subject:From:To:References:Date:In-Reply-To:From:To:CC:Subject; b=d6huB7jRJvPbJpkl38AkyCuAqwM9lptfh0xU1QcFn0zq5kHziXbKbV2jSelMEmDUk PQ8Re6HQHlAx+qJSVi6nYltorr1A6RkhP1A25M9/3n/gg/UdKhMFFcz3lF+4/OzwZ/ 0FAl6z6odqQzkwl5g0WthmJcyRuhOCl3pntAKQ0FMlqccxNRHtPk9mlLFEkauvnv6O U/PH7QTAw9xxWLX2JWHBaxbASY1FaKL9Mc6mhKKiJB1+t2Vbb0GPR+06DDhdhsyroA hySaUJkOpD6E172zWxPy8YvcgqvTATBsyHCG10XM0kALwg5Bw7S5hlWnKHhsK2gQ33 PgsNOS1lJc8dw== X-Virus-Scanned: amavisd-new at boeck2.rrze.uni-erlangen.de (RRZE) X-RRZE-Flag: Not-Spam X-RRZE-Submit-IP: 10.21.40.252 Received: from [10.21.40.252] (faustud-010-021-040-252.pool.uni-erlangen.de [10.21.40.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: U2FsdGVkX1+CTn7CfXxnzGu2JqZItrkjEUjhRrmCJ24=) by smtp-auth.uni-erlangen.de (Postfix) with ESMTPSA id 3yrHzc5rHCz8ssg for ; Mon, 4 Dec 2017 22:28:12 +0100 (CET) Subject: Re: ACPICA missing support for device I/O port ranges From: =?UTF-8?Q?Harald_B=c3=b6hm?= To: freebsd-hackers@freebsd.org References: <2497671.hb7Q7Esj6H@ralph.baldwin.cx> Message-ID: Date: Mon, 4 Dec 2017 22:28:12 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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: Mon, 04 Dec 2017 21:28:20 -0000 > >> IO ranges are not supposed to be in _CRS. An IO range is used for relocatable >> resources and would be in _PRS to say "you can use I/O ports at addresses, 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 range >> 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 >= 0xcf8 (range min) >> and <= 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 0x780 -> >> 0x88f, etc.). > > Thanks for the explanation, after reading it and having a look at the > ACPI spec everyhing makes much more sense now. :) > >> Probably it's just a bug in your BIOS and it means to use >> 0x700 -> 0x7ff and the BIOS author doesn't understand what Range Maximum 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 the >> spec says). > > From what I know about the device so far, this seems to be true. The > device only uses I/O ports in the range between 0x700 and 0x7FF, that's > why I was confused in the first place. It also seems to be the only > device that has this buggy port description in my BIOS, all other device > entries look like the example you gave. > > The affected Laptop is a MacBook Pro 11,3. The device should be present > in Apple computers with two graphics cards, it is used to switch between > GPUs. So, if anyone else is using a Mac with two graphics cards, it > would be interesting to see, whether this bug is also present in other > machines (acpidump -td and search for GMUX). > >> Assuming the BIOS is buggy, we can add a hack for iorange that adds the >> resource if max == min + length and emit a warning under bootverbose about >> the BIOS being buggy. I've filed a PR[0] with a revised version of my patch. I'd be glad about feedback/review. Thanks, Harald Böhm [0] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224096