Date: Fri, 02 Apr 2004 14:04:48 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: nate@root.org Cc: jhb@FreeBSD.org Subject: Re: newbus ioport usage Message-ID: <20040402.140448.22549726.imp@bsdimp.com> In-Reply-To: <20040402123025.E3097@root.org> References: <20040203145412.P33636@root.org> <200402041047.17902.jhb@FreeBSD.org> <20040402123025.E3097@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20040402123025.E3097@root.org>
Nate Lawson <nate@root.org> writes:
: ACPI already abuses identify/probe/attach to get priority for different
: probe tasks. We've run out of places to stick things since those are the
: only 3 hooks provided.
The ISA bus uses a priority number to determine when to do the probe
of a given device. How does ACPI abuse things that isn't compatible
with this? Why can't ACPI do things in a similar way? Why is ACPI so
different than all other busses that it can't deal with things the
same way? Maybe it is different, but what I know about ACPI right now
is inconsistant with your assertions.
: As a transition approach, we can add a flag to the end of the driver
: structure that requests multi-pass attach. Legacy drivers or non-bus
: drivers that just need the old behavior leave the flag 0 by default.
: Drivers like acpi set the flag and parse the pass number (arg2).
I don't like this much at all. newbus isn't like that: either you
implement the interface or you don't, there's not flags around.
However a similar approach could be taken so that we don't screw all
the drivers with two different device_attach-like methods, so I don't
think that will be a problem. If we do this, we should do it for all
drivers.
: This yields:
:
: #define BUS_PASS_BUS_HARDWARE 100
: #define BUS_PASS_IRQ_SOURCES 200
: #define BUS_PASS_IRQ_CONSUMERS 300
: #define BUS_PASS_CLOCKS 400
: #define BUS_PASS_LAST 0xffffffff
:
: int device_attach(device_t dev, int pass);
:
: One question I have is whether this process would be repeated as we
: discover more depths of busses (e.g., the other side of bridges.)
I think that you are confusing two fundamental sets of things, or I
am. Depth of busses have nothing to do with the number of passes.
The entire tree of devices are already known after the
BUS_PASS_BUS_HARDWARE pass, at least how jhb@ and I were talking
about.
: If we decide to go this way, I'd like to get it in before 5-stable.
That's likely too agressive a time scale. There's a lot of newbus/pci
resource allocation in my p4 tree already.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040402.140448.22549726.imp>