From owner-freebsd-current@freebsd.org Tue Apr 19 19:26:22 2016 Return-Path: Delivered-To: freebsd-current@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 28EEFB14C7D for ; Tue, 19 Apr 2016 19:26:22 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (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 09337104A for ; Tue, 19 Apr 2016 19:26:22 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 40E9AB99B; Tue, 19 Apr 2016 15:26:20 -0400 (EDT) From: John Baldwin To: Howard Su Cc: freebsd-current@freebsd.org Subject: Re: Mis-use of BUS_PASS_ORDER_MIDDLE Date: Tue, 19 Apr 2016 09:32:54 -0700 Message-ID: <2291840.VrgKOUFVXv@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: References: <1611132.EbTME86UTe@ralph.baldwin.cx> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 19 Apr 2016 15:26:20 -0400 (EDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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: Tue, 19 Apr 2016 19:26:22 -0000 On Tuesday, April 19, 2016 03:42:40 PM Howard Su wrote: > On Tue, Apr 19, 2016 at 2:53 AM John Baldwin wrote:= >=20 > > On Monday, April 18, 2016 11:10:12 PM Howard Su wrote: > > > I noticed several places there are code like this, especially in = some arm > > > low level drivers. > > > EARLY_DRIVER_MODULE(aw_ccu, simplebus, aw_ccu_driver, aw_ccu_devc= lass, > > > 0, 0, BUS_PASS_BUS + BUS_PASS_ORDER_MIDDLE); > > > > > > =E2=80=8BI feel the usage of BUS_PASS_ORDER_MIDDLE is misused. Th= ere are another > > > macro EARLY_DRIVER_MODULE_ORDERED, which take an additional param= eter > > > "order". I believe BUS_PASS_ORDER_xxx is used for that parameter.= > > > > No, this is actually correct. The _ORDERED variants actually accep= t a > > SI_ORDER_* value to determine how drivers contained in a single .ko= file > > are registered (in particular if you have several drivers in a .ko = file > > you typically want the "top-most" driver to attach last so that all= the > > other drivers are ready once the actual device is attached). > > > Why not use _ORDERED here to achieve same thing? _ORDERED(...., > SI_ORDER_LAST, BUS_PASS_BUS)? >=20 > I am thinking to add some macro like BUS_DRIVER_MODULE, INT_DRIVER_MO= DULE, > TIMER_DRIVER_MODULE, so that the driver can declare itself in such wa= y. If > we can avoid usage of BUS_PASS_ORDER_XXX, the macro is much cleaner. >=20 > I am plan to do is: in autoconf phase, first load timer, int and some= bus, > etc low level drivers first, then set cold=3D0, then load other drive= r to > work around the problem that driver needs special handling on cold wh= ich is > not necessary. of course, this may depends on your change of ap_start= up. > thoughts? I would like to get to that, but the path on x86 is a bit messier. Ide= ally the order looks something like this: - enumerate the tree (BUS_PASS_BUS) - reserve fixed-resources (things like acpi_sysres) (BUS_PASS_RESOURCE)= - reserve existing resources that could be moved or disabled if their is a conflict (think PCI BARs programmed by firmware and/or doing an initial pass of BARs) - interrupt controllers (may need resources) (BUS_PASS_INTR) - timers (probably need resources, need interrupts) (BUS_PASS_TIMER) Then all the rest. However, it ends up a bit messier on x86 at least. I have a WIP to at least start doing BUS_PASS_BUS for x86, but I found that I really need some ACPI bits to probe before the ACPI 'pcib' driver, so I've ended up with a kind of 'BUS_PASS_PREBUS' for acpi0, and even then it turns o= ut that in some cases we need more granularity than just 'BUS_PASS_xxx'. SI_ORDER_* with ORDERED will not help as all the drivers are registered= at SI_SUB_DRIVERS during boot (which is when the SI_ORDER_* applies), but the device tree is enumerated and attached at SI_SUB_CONFIGURE. And yes, the AP startup stuff is a precursor for this. --=20 John Baldwin