o Cut out the probed stuff. We no longer need it since newbus implicitly
checks for this (likely bt can be changed as well in this way).
o Add preliminary support for unload. Untested because aha doesn't yet
support identify and there are some interactions with PnP that I've
not yet worked out.
With this I can boot the AHA-1542CP FW F.0. All the aha resources
appear to be picked up via pnp now.
The files were repo copied from their original location and are part
way towards being portable.
This should unbreak the EISA support in the driver.
I have not updated files* yet as I'm not quite finished.
dynamic resource tables rather than relying on a duplicated cam-specific
table generated by config(8) in ioconf.c. This was a major holdup to
getting loader / userconfig driven configuration of scsi wiring.
the resource table to locate children. The 'at ppbus?' can go again.
Remove a few #if Nxxx > 0' type things, config arranges this for us.
Move the newbus method glue next to the DRIVER_MODULE() stuff so we
don't need extra prototypes.
Don't set device descriptions until after the possibility of the probe
returning an error.
Remove all cdevsw_add() calls, all the drivers that did this also use
make_dev() correctly, so it's not required.
A couple of other minor nits.
isa_device->id_ri_flags and RI_FAST were not implemented and did nothing.
The two drivers that were mistakenly thinking this was working were
cy.c and loran.c - these should be converted to newbus.
GC (garbage collect) isa_device->id_alive
GC userconfig.c references to isa_device->id_scsiid (!).
Fix a long-standing bug where I used a 'break;' instead of a 'continue;';
you had to have multiple ISA boards in non-PnP mode with an 'unknown' board
with a lower MAC address to find this one. Since I have 4 3c5x9 boards
in my test box I was somewhat confused when this happened. :)
Make the messages printed by ep_isa_identify() a little more consistent;
we'll only see them in verbose boot mode but it makes me feel better if
they look nice.
Also, while I'm here, add a mechanism to catch unknown board IDs that
are likely to be 3c509s and allow them to be attached.
PR: kern/16304
Submitted by: Kelly Yancey <kbyanc@posi.net>
the receive code so that it correctly chains receive descriptors together
and handles the case that only a part of a packet is done at the time
we get here.
