From owner-freebsd-acpi@FreeBSD.ORG Mon Jul 10 02:45:19 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 962A316A4E1; Mon, 10 Jul 2006 02:45:19 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 376B943D49; Mon, 10 Jul 2006 02:45:19 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [IPv6:::1] (may be forged)) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k6A2hKW3008028; Sun, 9 Jul 2006 20:43:21 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 09 Jul 2006 20:43:29 -0600 (MDT) Message-Id: <20060709.204329.-1889954042.imp@bsdimp.com> To: marcel@xcllnt.net From: "M. Warner Losh" In-Reply-To: References: <200607071240.57062.jhb@freebsd.org> <20060709.014658.-460542464.imp@bsdimp.com> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org, atkin901@yahoo.com Subject: Re: acpi on msi-9218 (-current) swaps sio0 and sio1 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2006 02:45:19 -0000 In message: Marcel Moolenaar writes: : On Jul 9, 2006, at 12:46 AM, M. Warner Losh wrote: : : > Finally, there's the redundant specification problem. People want : > sio0 to attach to this thing in the back of the computer that's : > labeled COMA, and whose resources are this or that. They know from : > their computer's documentation that this is COM1, and windows assigns : > it to COM1. This desire is due in part to it being the way we've : > always selected sio0. It traditionally has been the serial port at : > address 0x3f8. There's also the problem that the low level kernel : > console driver wants to talk to the port by address, while the newbus : > system wants to talk to it by how it probed. So you get odd : > cross-threading when these two don't agree. If the cross threading : > didn't exist, and the right thing happened, users wouldn't care how : > that happened. : : uart(4) has this problem solved already. It seems to me from following : the various mailing lists that it's probably time to think about phasing : out sio(4), because problems tend to come up with sio(4) from time to : time that have already been solved with uart(4). It solves one tiny sliver of this problem. While there may be other merit for using uart(4) over sio(4), this one issue isn't it. At the very least, there'd be a high cost of migration from /dev/ttyd0 to /dev/ttyu0. Our products were bit by the cuaa0 -> cuad0 changes between 5.x and 6.x, and that made a lot of people around unhappy. They'd be even more unhappy if it changed again. : > ... The third problem could : > also be solved with hints and some minor adjustments to newbus. : : I disagree. It's misusing hints that's causing the cross-threading. : If hints were to be used for enumeration only and you have a different : means to select the low-level serial console then cross-threading is : avoided. This is exactly what uart(4) does. As such, you can even pick : a port on a multi-I/O PCI card for the low-level serial console : without causing interference with any of the other problems you : mentioned. The reason is simply that you select the low-level serial : console by the one attribute that matters: the I/O address (either : I/O port or memory mapped I/O). You are correct for the console issue. But the problem is much bigger than just the console issue. My company uses single board computers for its embedded products. The documentation for the SBC says that this spigot is COM1 or that spigot is COM2. The hardware folks then design the cables and such for the individual unit, plug it all together and tell the software folks that thus and such function is on COM1 and whatsit is on COM2. It is perceived to be a FreeBSD bug that sio0 isn't COM1 and sio1 isn't COM2. This is espeically true when we swap out boards as the old one goes obsolete (which happens far too quickly). We've had some boards whose tables are such that com1 <-> sio0 and others where com1 <-> sio1. We've avoided this issue by not using ACPI, but we're starting to find that it's harder to get vendors to fix problems with non-acpi operation. There are many valid reasons for wanting to wire the unit number to a resource. Warner