Juergen Keil wrote:
>
>>>Looking at the code in scsa2usb_rw_transport(), I'd say this special case
>>>isn't handled correctly, when translating from SCMD_READ/SCMD_WRITE to
>>>SCMD_READ_G1/SCMD_WRITE_G1.
>>>
>>>I think for a correct read/write(6) implementation, we need something
>>>like this:
>>>
>>> switch (opcode) {
>>> case SCMD_READ:
>>> /*
>>> * Note that READ/WRITE(6) are not supported by the drive.
>>> * convert it into a 10 byte read/write.
>>> */
>>> lba = SCSA2USB_LBA_6BYTE(pkt);
>>> len = SCSA2USB_LEN_6BYTE(pkt);
>>> if (len == 0) len = 256;
>
> <<<<<<<<<<<<<<<<<<<<<<<<<<
>
>>> opcode = SCMD_READ_G1; /* Overwrite it w/ byte 10 cmd val
>
> */
>
>>> dir = USB_EP_DIR_IN;
>>> break;
>>> case SCMD_WRITE:
>>> lba = SCSA2USB_LBA_6BYTE(pkt);
>>> len = SCSA2USB_LEN_6BYTE(pkt);
>>> if (len == 0) len = 256;
>
> <<<<<<<<<<<<<<<<<<<<<<<<<<
>
>>> opcode = SCMD_WRITE_G1; /* Overwrite it w/ byte 10 cmd val
>
> */
>
>>> dir = USB_EP_DIR_OUT;
>>> break;
>>>
>>>
>>
>>You are right. But we haven't seen this problem so far. Perhaps sd never
>>sends a read/write(6) with zero length. So it may not be a real issue.
>>I'll check if we need to add this.
>
>
>
> An user level application using USCSI ioctls could send them.
>
>
> sd_send_scsi_RDWR() contains some code to send read/write(6).
> But it might be impossible to make it send a read/write(6) cdb
> with 256 sectors.
>
>
> Otherwise, sd seems to avoid this case because the maximum block
> count for CDB_GROUP0 is set to 255, not 256:
>
> static struct sd_cdbinfo sd_cdbtab[] = {
> { CDB_GROUP0, 0x00, 0x1FFFFF, 0xFF, <<<<< },
> { CDB_GROUP1, SCMD_GROUP1, 0xFFFFFFFF, 0xFFFF, },
> { CDB_GROUP5, SCMD_GROUP5, 0xFFFFFFFF, 0xFFFFFFFF, },
> { CDB_GROUP4, SCMD_GROUP4, 0xFFFFFFFFFFFFFFFF, 0xFFFFFFFF, },
> };
>
>
I'll double check and try the uscsi command to ensure read/write(6) also
works.
Thanks,
Sophia
