From owner-freebsd-acpi@FreeBSD.ORG Mon Jul 10 05:37:40 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 3090416A4DD; Mon, 10 Jul 2006 05:37:40 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id A538443D53; Mon, 10 Jul 2006 05:37:39 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from [192.168.4.150] (pptp0.pn.xcllnt.net [192.168.4.150]) by ns1.xcllnt.net (8.13.6/8.13.6) with ESMTP id k6A5bVpe023687; Sun, 9 Jul 2006 22:37:32 -0700 (PDT) (envelope-from marcel@xcllnt.net) In-Reply-To: <20060709.204329.-1889954042.imp@bsdimp.com> References: <200607071240.57062.jhb@freebsd.org> <20060709.014658.-460542464.imp@bsdimp.com> <20060709.204329.-1889954042.imp@bsdimp.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0353311F-34F9-40F6-81B9-C7C838CC6024@xcllnt.net> Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Sun, 9 Jul 2006 22:37:26 -0700 To: "M. Warner Losh" X-Mailer: Apple Mail (2.752.2) 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 05:37:40 -0000 On Jul 9, 2006, at 7:43 PM, M. Warner Losh wrote: > : > ... 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. I beg to differ. You correctly separated the low-level console issue from the need to have a fixed mapping between port (plug/socket) and unit numbers. The problems are separate and uart(4) correctly solves the low-level console to unit mapping. This means that with uart(4) you always have a single-user console, even though it may not be on the same unit number when hardware configurations change. That latter is the problem of having to wire-down a unit number and can best be illustrated by having to edit /etc/ttys when unit numbers change (or changing rc.conf when network units change -- take a pick :-). You like to be able to fixate that, so that you don't have to edit your favorite configuration file. This problem cannot and/or should not be solved by any individual driver, but should be handled at the bus level. So, we're talking about two different problems here, because they need to be solved at different "levels" in the newbus framework. Trying to solve them with a single solution or treating them as a single problem is exactly what will cause the cross-threading you mentioned. > There are many valid reasons for wanting to wire the unit number to a > resource. Agreed, and this has nothing to do with low-level console issues. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net