on a per target basis (until the driver can sort things out on its own).
Test against "sbus" in stead of "espdma" to find out where in the
configuration tree we are: an esp can be the child of a "dma" on SBus
add-on boards.
- properly do MSG_IN handshaking, so we can actually receive multi-byte msgs.
- do synch negotiation (now that the above works).
- handle disconnects.
There are a few trial-and-error bits at points where the docs I have are
particularly ambiguous about the state of chip and/or SCSI bus.
Things to do:
- more cleanup
- deal with MSG_OUT phase better
- keep some "config reg 3" bits per target (ie. FASTCLK and FASTSCSI).
- make esp_poll() approximate the given timeout value.
- introduce esp_abort(), and use it for timed out commands; make targets and driver less confused.
- make {free,ready,nexus}-list management somewhat more coherent.
- make sure we only proceed down the state machine in espintr()
if there really is an interrupt pending.
get an "Illegal command" (why is this?) when we try to pull it in.
On detection of this condition, we reset the SCSI bus and simply stop asking
this target for an identify messages, for now.
pk