> > 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, },
};
