Ben Harris <bjh21@netbsd.org> writes:
> Right, so is your problem with there being a separate batch of bus
> attachments for each type of multi-I/O chip?

yes.  There may be more, but to be honest I've not been following
closely enough...  8-)


> If so, would an MI version
> of the amiga supio stuff be acceptable?

sort-of.

I think you're probably best off having a bus, call it 'dcisa' or who
knows what, to which attach devices.  As with ISA, that bus gets a
bunch of function pointers, etc., that indirect to code provided by
the chip driver.  The chip driver also provides a table of devices.
(probably shouldn't use driver names for the purpose, but rather
constants.)

I'd prefer that, rather than a generic super-io chip device (with all
the chip-specific guts in the match/attach routines) for a couple of
reasons:

(1) it makes it easier to support multiple types of super-io chips on
a single platform/bus.  (i.e. if the guts are in the match/attach, of
which you can have only one per bus, then if you need to support
multiple chips you start getting hairy).

(2) it better accomodates the specification and selection of built-in
devices.


Really, in a perfect world, 'isa' would be augmented to take a table
from the MD implementation, and pass an extra argument along in the
isa_attach_args indicating direct configuration, and config_found()
all of the direct-config devices specified in the table, and then
optionally also do indirect configuration for the rest.

To my mind, _this_ is the correct model for operation, because, in a
nutshell, on some systems you have built-in devices at known locations
on isa, and then you have add-in devices as well.

The former should be expressible via direct configuration.



chris