I think you have to check your facts about command queing...
you wrote :
Details on CQ,
A queue (for any type of command queuing ATA, SATA or SCSI) is initiated when the drive sends a "queued" response back to the host instead of a "busy" response. A command queuing enabled host can then send more commands if it has any lying around.
I know for a fact (for SCSI at least) that the drive is not the one deciding if it will do queing or not...
If the drive can do it and the host (HBA/driver/OS) supports it, then each command can have a 'tag', and the drive can have up to 256 active one at once, and sort them as it wishes...
So the drive is not the one initiating command queing.
This means that if the host side has more than one command to send to the same drive, it will assign a tag to each command that the drive has to reply with.
As the drive of the HBA will create the tag, a memory location is the most likely 'tag' to be used : the memory location of the queue used by the driver (ever done link list ?). Like that, when the HBA/driver get a reply back, it knows where to look for storing info about this command... and it is unique.
You wrote :
As I noted in my last post the commands are queued by the drive in ATA, SATA and SCSI command queuing. This CQ is done in hardware (although in ATA and SATA the host is actually software, so the host side can be done in software).
The CQ is done at a firmware level assisted by hardware to speed up things...
I thought this was pointed out to you a while back in an other thread, but it looks like you are still confused about the drive side...
(Au pays des aveugles les borgnes sont rois!)