Alan Stern wrote:
On Wed, 19 Jan 2005, Vladimir Trukhin wrote:
That's it!One useful experiment might be disabling the call to halt that endpoint, to see if that makes MS-Windows happier.
That was the source of my problem. But actually it doesn't matter whether or not it's a zero length packet. Anyway, the usb controller doesn't send a packet if halt has been called (at least, I can't see it on Windows side with sniffer).
The controller driver is supposed to return -EAGAIN if it has been asked to halt an IN endpoint that has data still in the fifo. Take a look at the halt_bulk_in_endpoint routine in file_storage.c.
Well, looks like pxa2xx_udc doesn't return the error status if halt has been issued after sending a zero-length packet.
It always responds with zero as can be seen from log file:
--------------------------------------------------------------------------
...
<7>g_file_storage gadget: SCSI command: READ FORMAT CAPACITIES; Dc=10, Di=252; Hc=2
<7>g_file_storage gadget: bulk-in, length 0:
<7>g_file_storage gadget: bulk-in set halt
<7>udc: ep1in-bulk halt
<7>g_file_storage gadget: sending command-failure status
...
--------------------------------------------------------------------------
<7>udc: ep1in-bulk halt - this line from the log corresponds to successful exit from pxa2xx_ep_set_halt() call.
But this packet has never been delivered to the Windows's host controller. (or, as I mentioned, I can't see it with sniffer?!)
So the following conditions are always FALSE in this context. Seems like the hardware (UDCCS registers specifically) doesn't give us the correct status info.
----------- taken from pxa2xx_udc.c:pxa2xx_ep_set_halt() -----------
...
1081 if ((ep->bEndpointAddress & USB_DIR_IN) != 0
1082 && ((*ep->reg_udccs & UDCCS_BI_TFS) == 0
1083 || !list_empty(&ep->queue))) {
1084 local_irq_restore(flags);
1085 return -EAGAIN;
1086 }
...
---------------------------------------------------------------------------------------When I disabled halting it passed READ FORMAT CAPACITIES command but stopped at some others.
Unfortunately, I have no time now to debug it deeply.
What were the other commands that caused trouble?
Sorry! My mistake. Seems then I didn't remove some debug outputs and it caused the fail during connection.
Today I tried it again with the original sources and stall=0 and found that it worked fine.
But with 'removable' option and disabled halting it connects and works fine with both Linux and Windows.
Anyway, for my immediate aim it's more than enough.
By and large, to make it works I just made the following change:
--- file_storage.c 2004-12-25 06:36:01.000000000 +0900 +++ file_storage.c 2005-01-14 14:18:51.000000000 +0900 @@ -3714,7 +3714,7 @@ mod_data.protocol_type = USB_SC_SCSI; mod_data.protocol_name = "Transparent SCSI";
- if (gadget_is_sh(fsg->gadget)) + if (gadget_is_sh(fsg->gadget) || gadget_is_pxa(fsg->gadget)) mod_data.can_stall = 0;
if (mod_data.release == 0xffff) { // Parameter wasn't set
You don't need to do this. Just use the 'stall=no' module parameter when the driver is loaded.
Ok, but g_file_storage accepts this parameter only in test version (CONFIG_USB_FILE_STORAGE_TEST).
But what should I do if I don't use test mode?
Best regards, Vlad Trukhin
------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
