From owner-freebsd-arch@FreeBSD.ORG Fri Apr 2 13:04:29 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9D09116A4CE; Fri, 2 Apr 2004 13:04:29 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id B78E143D48; Fri, 2 Apr 2004 13:04:28 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id i32L4Rkj062427; Fri, 2 Apr 2004 14:04:27 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 02 Apr 2004 14:04:48 -0700 (MST) Message-Id: <20040402.140448.22549726.imp@bsdimp.com> To: nate@root.org From: "M. Warner Losh" In-Reply-To: <20040402123025.E3097@root.org> References: <20040203145412.P33636@root.org> <200402041047.17902.jhb@FreeBSD.org> <20040402123025.E3097@root.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: arch@FreeBSD.org cc: jhb@FreeBSD.org Subject: Re: newbus ioport usage X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2004 21:04:29 -0000 In message: <20040402123025.E3097@root.org> Nate Lawson writes: : ACPI already abuses identify/probe/attach to get priority for different : probe tasks. We've run out of places to stick things since those are the : only 3 hooks provided. The ISA bus uses a priority number to determine when to do the probe of a given device. How does ACPI abuse things that isn't compatible with this? Why can't ACPI do things in a similar way? Why is ACPI so different than all other busses that it can't deal with things the same way? Maybe it is different, but what I know about ACPI right now is inconsistant with your assertions. : As a transition approach, we can add a flag to the end of the driver : structure that requests multi-pass attach. Legacy drivers or non-bus : drivers that just need the old behavior leave the flag 0 by default. : Drivers like acpi set the flag and parse the pass number (arg2). I don't like this much at all. newbus isn't like that: either you implement the interface or you don't, there's not flags around. However a similar approach could be taken so that we don't screw all the drivers with two different device_attach-like methods, so I don't think that will be a problem. If we do this, we should do it for all drivers. : This yields: : : #define BUS_PASS_BUS_HARDWARE 100 : #define BUS_PASS_IRQ_SOURCES 200 : #define BUS_PASS_IRQ_CONSUMERS 300 : #define BUS_PASS_CLOCKS 400 : #define BUS_PASS_LAST 0xffffffff : : int device_attach(device_t dev, int pass); : : One question I have is whether this process would be repeated as we : discover more depths of busses (e.g., the other side of bridges.) I think that you are confusing two fundamental sets of things, or I am. Depth of busses have nothing to do with the number of passes. The entire tree of devices are already known after the BUS_PASS_BUS_HARDWARE pass, at least how jhb@ and I were talking about. : If we decide to go this way, I'd like to get it in before 5-stable. That's likely too agressive a time scale. There's a lot of newbus/pci resource allocation in my p4 tree already. Warner