From owner-svn-src-all@freebsd.org Mon Mar 5 18:20:53 2018 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CFC62F45037; Mon, 5 Mar 2018 18:20:52 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7EA1387288; Mon, 5 Mar 2018 18:20:52 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (ralph.baldwin.cx [66.234.199.215]) by mail.baldwin.cx (Postfix) with ESMTPSA id 2308F10A87D; Mon, 5 Mar 2018 13:20:51 -0500 (EST) From: John Baldwin To: Emmanuel Vadot Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r330335 - head/sys/sys Date: Mon, 05 Mar 2018 09:40:25 -0800 Message-ID: <1619920.YOJitH0Jj0@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.1-STABLE; KDE/4.14.30; amd64; ; ) In-Reply-To: <201803031243.w23ChBMQ096308@repo.freebsd.org> References: <201803031243.w23ChBMQ096308@repo.freebsd.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Mon, 05 Mar 2018 13:20:51 -0500 (EST) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 18:20:53 -0000 On Saturday, March 03, 2018 12:43:11 PM Emmanuel Vadot wrote: > Author: manu > Date: Sat Mar 3 12:43:11 2018 > New Revision: 330335 > URL: https://svnweb.freebsd.org/changeset/base/330335 > > Log: > Introduce BUS_PASS_SUPPORTDEV > > The reason for this new pass is : > > The earlier pass names are really specific (interrupt, timer, scheduler etc ..) > and making a driver that other device driver (that attach at DEFAULT pass) > needs probe at earlier pass can be confiusing. We can live with GPIO driver > at INTERRUPT pass because they are often an interrupt controller too but having > a usb phy driver probed at RESOURCES (or SCHEDULER for example) is silly. > The number was choosen to have a lot of margin if we want to introduce other > pass in the futur. > > Reviewed by: ian, imp, kevans > Differential Revision: https://reviews.freebsd.org/D14568 I have a different issue on x86 which is that I want acpi0 to kind of probe even before BUS_PASS_BUS. I've wondered if the pass stuff actually needs to be recursive in some way. That is, when a bus first enumerates children, we start probing drivers for those children starting at pass 0 and working up to the current global pass level before increasing the global pass level. This scheme would also making bus passes still operate the same in a post-boot environment as the I think an implementation would mean that each bus device had its own pass level that governed the attach logic and we would raise that pass level up across the different levels to the current level when attaching a new bus device. (I would perhaps handle this logic in bus_generic_attach() to make it transparent to bus drivers.) Do you have any thoughts on that and if it would help with any situations you are aware of? It would mean that if some new bus was discovered when the global pass level was a higher number, the new bus could still "step up" through the pass levels. -- John Baldwin