newbus ioport usage

M. Warner Losh imp at bsdimp.com
Fri Apr 2 13:04:29 PST 2004


In message: <20040402123025.E3097 at root.org>
            Nate Lawson <nate at 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


More information about the freebsd-arch mailing list