Re: [PATCH v2 2/3] usb: gadget: file_storage: Make CD-ROM emulationwork with Mac OS-X
From: Roger Quadros
Date: Tue Mar 22 2011 - 10:37:05 EST
On 03/22/2011 04:26 PM, ext Alan Stern wrote:
On Tue, 22 Mar 2011, Roger Quadros wrote:
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?
No. Always return the actual TOC length.
OK.
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;
Not needed (and not correct). The code at the end of do_scsi_command()
already does this:
reply = min((u32) reply, fsg->data_size_from_cmnd);
...
fsg->residue -= reply;
Oh yes, this explains why to return the actual TOC length in do_read_toc().
However, if host asked for data more than the TOC length then residue will be
greater than zero and this will result in zero padded transfers.
Not a big issue but should we be fixing it?
one way could be to set fsg->residue to actual TOC length. in do_read_toc().
--
regards,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/