Re: Mis-use of BUS_PASS_ORDER_MIDDLE

Can we only load the bus driver that is required by timer or pic? Then you
don't need worry about acpi_pci or pcib.

John Baldwin <jhb_at_freebsd.org>于2016年4月20日周三 上午3:26写道：

> On Tuesday, April 19, 2016 03:42:40 PM Howard Su wrote:
> > On Tue, Apr 19, 2016 at 2:53 AM John Baldwin <jhb_at_freebsd.org> wrote:
> >
> > > 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_devclass,
> > > >     0, 0, BUS_PASS_BUS + BUS_PASS_ORDER_MIDDLE);
> > > >
> > > > ​I feel the usage of BUS_PASS_ORDER_MIDDLE is misused. There are
> another
> > > > macro EARLY_DRIVER_MODULE_ORDERED, which take an additional parameter
> > > > "order". I believe BUS_PASS_ORDER_xxx is used for that parameter.
> > >
> > > No, this is actually correct.  The _ORDERED variants actually accept 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)?
> >
> > I am thinking to add some macro like BUS_DRIVER_MODULE,
> INT_DRIVER_MODULE,
> > TIMER_DRIVER_MODULE, so that the driver can declare itself in such way.
> If
> > we can avoid usage of BUS_PASS_ORDER_XXX, the macro is much cleaner.
> >
> > I am plan to do is: in autoconf phase, first load timer, int and some
> bus,
> > etc low level drivers first, then set cold=0, then load other driver to
> > work around the problem that driver needs special handling on cold which
> is
> > not necessary. of course, this may depends on your change of ap_startup.
> > thoughts?
>
> I would like to get to that, but the path on x86 is a bit messier.  Ideally
> 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 out
> 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.
>
> --
> John Baldwin
>
-- 
-Howard