From owner-svn-src-head@freebsd.org Wed Apr 27 19:43:06 2016 Return-Path: Delivered-To: svn-src-head@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 8C80CB1FBEA; Wed, 27 Apr 2016 19:43:06 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "alchemy.franken.de", Issuer "alchemy.franken.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0AFBA13C1; Wed, 27 Apr 2016 19:43:05 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.15.2/8.15.2/ALCHEMY.FRANKEN.DE) with ESMTPS id u3RJUZXJ094676 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 27 Apr 2016 21:30:35 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.15.2/8.15.2/Submit) id u3RJUZ59094675; Wed, 27 Apr 2016 21:30:35 +0200 (CEST) (envelope-from marius) Date: Wed, 27 Apr 2016 21:30:35 +0200 From: Marius Strobl To: John Baldwin Cc: src-committers@freebsd.org, svn-src-head@freebsd.org, svn-src-all@freebsd.org Subject: Re: svn commit: r298712 - in head/sys: dev/cardbus kern mips/nlm powerpc/ofw sparc64/pci sys Message-ID: <20160427193035.GA93595@alchemy.franken.de> References: <201604271749.u3RHngl6051451@repo.freebsd.org> <2789741.CjRGbn4rPl@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2789741.CjRGbn4rPl@ralph.baldwin.cx> User-Agent: Mutt/1.5.24 (2015-08-30) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (alchemy.franken.de [0.0.0.0]); Wed, 27 Apr 2016 21:30:35 +0200 (CEST) X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 19:43:06 -0000 On Wed, Apr 27, 2016 at 10:54:42AM -0700, John Baldwin wrote: > On Wednesday, April 27, 2016 05:49:42 PM John Baldwin wrote: > > Author: jhb > > Date: Wed Apr 27 17:49:42 2016 > > New Revision: 298712 > > URL: https://svnweb.freebsd.org/changeset/base/298712 > > > > Log: > > Add a bus_null_rescan() method that always fails with an error. > > > > Use this in place of kobj_error_method to disable BUS_RESCAN() on > > PCI drivers that do not use the "standard" scanning algorithm. > > This should fix the build. > > > Modified: > > head/sys/dev/cardbus/cardbus.c > > head/sys/kern/subr_bus.c > > head/sys/mips/nlm/xlp_pci.c > > head/sys/powerpc/ofw/ofw_pcibus.c > > head/sys/sparc64/pci/ofw_pcibus.c > > head/sys/sys/bus.h > > Note that some of these drivers could be changed to use the "standard" > scanning algorithm and support rescans if they moved some of their custom > scanning logic into a pci_child_added callback. This is generally true of > all but cardbus except that the OFW busses use the OFW tree to drive > scanning (so it seems they will add PCI devices that don't appear valid to > a PCI scan but are in the OFW tree). As for sparc64, the latter isn't true AFAICT, i. e. all PCI devices added based on information obtained from the device tree should also be found with the "standard" scanning method (apart from 2 or 3 known dupes with partially incomplete information in the known device trees; these nodes are skipped, though). Actually, IIRC "standard" PCI device scanning is how things worked before the OFW_NEWPCI code was added in r117119. However, OFW information is used for enumerating PCI busses and devices since then so the order within FreeBSD matches connector/ port markings on chassis and add-on cards (i. e. on-board MACs end up as bge[0-3], an add-on card gets bge4, analogous for multi-port cards, same for HBAs etc.), which previously wasn't the case with "standard" scanning. So what could work for sparc64 is to do a first pass still based on OFW information and then a second one using the "standard" scanning method, especially in the rescan case. However, given that at least some sun4u models support PCI hot-plug it's also not totally unthinkable that OFW nodes for PCI devices will be added/removed on the fly; so far I just wasn't adventurous enough to give that a try, though. Marius