Hi,
On 03/21/2011 12:59 PM, ext Roger Quadros wrote:
@@ -1703,18 +1705,21 @@ static int do_read_toc(struct fsg_dev *fsg, struct fsg_buffhd *bh)
return -EINVAL;
}
- memset(buf, 0, 20);
- buf[1] = (20-2); /* TOC data length */
- buf[2] = 1; /* First track number */
- buf[3] = 1; /* Last track number */
- buf[5] = 0x16; /* Data track, copying allowed */
- buf[6] = 0x01; /* Only track is number 1 */
- store_cdrom_address(&buf[8], msf, 0);
+ format = fsg->cmnd[2]& 0xf;
+ /*
+ * Check if CDB is old style SFF-8020i
+ * i.e. format is in 2 MSBs of byte 9
+ * Mac OS-X host sends us this.
+ */
+ if (format == 0)
+ format = (fsg->cmnd[9]>> 6)& 0x3;
- buf[13] = 0x16; /* Lead-out track is data */
- buf[14] = 0xAA; /* Lead-out track number */
- store_cdrom_address(&buf[16], msf, curlun->num_sectors);
- return 20;
+ ret = fsg_get_toc(curlun, msf, format, buf);
+ if (ret< 0) {
+ curlun->sense_data = SS_INVALID_FIELD_IN_CDB;
+ return -EINVAL;
+ }
+ return ret;
}
I have a question here.
The host can request us to send less or more than the actual TOC size, since it
has no clue how big it is.
e.g. Linux host requests us to send only 12 bytes even though our formatted TOC
length is 20. In this case should we return fsg->data_size_from_cmnd instead of
actual TOC length?
e.g. Mac requests us to send 65534 bytes but our RAW TOC length is 37.
The file storage driver seems to be zero padding our data response. So we
respond with 65534 bytes, 37 of TOC and remaining zero padded.
Can we do something like this to avoid unnecessary zero padded transfers?
ret = fsg_get_toc(curlun, msf, format, buf);
if (ret < 0) {
curlun->sense_data = SS_INVALID_FIELD_IN_CDB;
return -EINVAL;
} else if (ret > fsg->data_size_from_cmnd) {
ret = fsg->data_size_from_cmnd;
} else {
fsg->residue = ret;
}
return ret;
--
regards,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
