On Sun, Mar 04, 2001 at 12:03:47AM -0600, [EMAIL PROTECTED] wrote:
> On Sat, Mar 03, 2001 at 06:59:52PM -0800, Matthew Dharm wrote:
> > You're basically right. The good news is that all devices so far which
> > need fake inquiry data are all direct-access devices.
> >
> > And fill_inquiry_response is there for exactly that reason. It probably
> > needs a little bit of work to make it perfectly usable by others, tho.
>
> Ok, I can see how fill_inquiry_response() needs to be fixed up, I just
> don't know how much. I don't know what is in the response data to an
> INQUIRY command. Is there a table in the code somewhere?
Nope. Search on the web for the SCSI-II command spec for the info.
> What I don't see is the right place to check the new flag and make the
> call to fill_inquiry_response(). My current guess is in
> usb_stor_invoke_transport(). I'm looking at a block of code like:
>
> if (srb->result == US_BULK_TRANSFER_SHORT &&
> srb->cmnd[0] == INQUIRY &&
> us->unusual_dev->flags & US_FL_FIX_INQUIRY) {
> char new_response[36];
>
> fill_inquiry_response(us, new_response, 36);
> }
>
> I believe we can see the short transfer status in srb->result. It
> doesn't make it to result because the IRQ data comes up zeros.
Close, but I'd rather head it off in the control thread. Look for the
special case code for devices that can't handle START_STOP.
> Am I getting closer?
Yes. :)
Matt
--
Matthew Dharm Home: [EMAIL PROTECTED]
Maintainer, Linux USB Mass Storage Driver
Department of Justice agent. I have come to purify the flock.
-- DOJ agent
User Friendly, 5/22/1998
PGP signature
