m. allan noah wrote: > most scsi commands that use a data block after the command block (mode > select, set window, scan) are formatted differently when sent via usb. the > command block is sent first, in a single urb, padded to 31 bytes with null > bytes. then the data block(s) are sent in another urb, not padded. > > the existing fujitsu code is very scsi specific, and only uses one buffer > for scsi cmd/data to the do_cmd() function. this means that the caller has > to either pad the single buffer with just the right number of 0's in the > middle of the buffer, or the do_usb_cmd() function will have to break the > buffer inhalf, and pad the data itself.
It's perhaps reasonable to call sanei_scsi_cmd2 instead of sanei_scsi_cmd. The former function needs/wants different buffers for the CDB and the write data. All OS specific SCSI interfaces (except the old Linux SG interface) use different buffers anyway, and in many cases the backends have also different buffers for CDB and data, so I expect that you can also avoid a few memcpy calls. And inside sanei_scsi, the function sanei_scsi_cmd tries to guess the CDB size and then calls sanei_scsi_cmd2 anyway. Abel
