From owner-freebsd-current@FreeBSD.ORG Wed Jun 11 07:26:12 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC8EB37B404 for ; Wed, 11 Jun 2003 07:26:12 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id E675143F93 for ; Wed, 11 Jun 2003 07:26:10 -0700 (PDT) (envelope-from tmoestl@gmx.net) Received: (qmail 23893 invoked by uid 65534); 11 Jun 2003 14:26:09 -0000 Received: from p508E7CCE.dip.t-dialin.net (EHLO galatea.local) (80.142.124.206) by mail.gmx.net (mp026) with SMTP; 11 Jun 2003 16:26:09 +0200 Received: from tmm by galatea.local with local (Exim 4.20 #1) id 19Q6YV-0004TD-BI; Wed, 11 Jun 2003 16:26:27 +0200 Date: Wed, 11 Jun 2003 16:26:27 +0200 From: Thomas Moestl To: "M. Warner Losh" , ticso@cicely.de, ticso@cicely12.cicely.de, freebsd-current@freebsd.org, freebsd-sparc64@freebsd.org Message-ID: <20030611142627.GB634@crow.dom2ip.de> Mail-Followup-To: "M. Warner Losh" , ticso@cicely.de, ticso@cicely12.cicely.de, freebsd-current@freebsd.org, freebsd-sparc64@freebsd.org References: <20030609.224621.71095461.imp@bsdimp.com> <20030610115615.GB10527@cicely12.cicely.de> <20030610121249.GE10527@cicely12.cicely.de> <20030610.082730.102566465.imp@bsdimp.com> <20030610223436.GC37257@funkthat.com> <20030610230230.GC734@crow.dom2ip.de> <20030610234144.GA39701@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030610234144.GA39701@funkthat.com> User-Agent: Mutt/1.4.1i Sender: Thomas Moestl Subject: Re: PCI bus numbering and orphaned devices X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2003 14:26:13 -0000 On Tue, 2003/06/10 at 16:41:44 -0700, John-Mark Gurney wrote: > Thomas Moestl wrote this message on Wed, Jun 11, 2003 at 01:02 +0200: > > On Tue, 2003/06/10 at 15:34:36 -0700, John-Mark Gurney wrote: > > There's a similar problem with hme devices in some Netra models, and > > so far I have just ignored this because of the ugliness involved > > (there were patches floating around at one point, but I did not commit > > them). > > > > The real fix (and the way I wanted to implement things from the > > beginning) is to write an OFW PCI bus, analogous to the ACPI one. This > > is high on my list, waiting for time to become available :) > > Yikes, I just started looking at the acpi code, and there's a lot of > code in it! There's much setup to be done that the firmware is too lazy to do for us. > > > Is this why pciconf -r is returning 0xffffffff when reading the ebus > > > and firewire parts of the SME2300BGA? Simply because it isn't in > > > the ofw tree? > > > > Could be. We just cannot handle devices without firmware nodes - we > > don't know whether we can safely access them, cannot assign interrupts > > etc. > > Ok, the only problem is that is then we have the same problem the ACPI > code does in that hot swapping cards would have a problem. Since it > appears to me that the OFW tree doesn't get updated upon a swap. (At > least the usb part of the tree doesn't.) We do not support hotplugging at the moment anyway. If a bridge driver would implement that in the future without using any firmware support however, it will then need to know everything information about the interrupt routing required for its devices if it cannot use the firmware for this. in that case, it can just prevent the ofw_pci bus from attaching to it (this will be easily possible). I'd hope that machines that support hot-plugging of PCI devices would have firmware methods available to support that though. > Does this mean that we should eliminate most of the Sun specific pci > bus drivers in favor of OFW specific ones like ACPI? or? No, it means introducing an OFW bus driver, which uses the firmware to enumerate the devices and to support interrupt routing. The bridge drivers would be mostly unaffected by this. The only problem with this approach is that it can change the device enumeration; I hope that the resulting one will be the same one that is printed on the boxen, so it should be advantageous for new installations, but a minor migration problem for old ones. I've got some code for this already, it just isn't done yet. - Thomas -- Thomas Moestl http://www.tu-bs.de/~y0015675/ http://people.FreeBSD.org/~tmm/ PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C