There's still a reference to adapter_q in the comments:

/* 
 * Each scsipi transaction is fully described by one of these structures  
 * It includes information about the source of the command and also the
 * device and adapter for which the command is destined.
 * 
 * The adapter_q member may be used by host adapter drivers to queue
 * requests, if necessary.
 *
 * The device_q member is maintained by the scsipi middle layer.  When
 * a device issues a command, the xfer is placed on that device's
 * pending commands queue.  When an xfer is done and freed, it is taken
 * off the device's queue.  This allows for a device to wait for all of
 * its pending commands to complete.
 */
struct scsipi_xfer { 
        TAILQ_ENTRY(scsipi_xfer) channel_q; /* entry on channel queue */
        TAILQ_ENTRY(scsipi_xfer) device_q;  /* device's pending xfers */
...

and no description about what channel_q does.

I intend to change the comment to say:

 * The channel_q member is used by the scsipi midlayer to queue up requests 
 * before and after the host adapter driver operates on the command. The
 * host adapter driver may use this field for queueing purposes while the
 * host adapter is running the command.

This *should* be safe enough. There's every reason to have some linked list of
currently active commands at the HBA level, and if we're concerned about
corruption or confusion, we'd better devote another tag.

Thoughts?

-matt