Alan,

On Tue, 2004-07-27 at 15:49 -0400, Alan Stern wrote:
> That's a problem in the controller driver.  Which driver are you using?  
> It should include something like this in its usb_gadget_register_driver() 
> routine (this is copied from net2280.c):
> 
>       dev->gadget.dev.driver = &driver->driver;
>       retval = driver->bind (&dev->gadget);
> 
> The first line sets the gadget controller's driver to the fsg driver
> immediately before calling fsg_bind().

OK, you are right, that was the source of the problem. Now we already
fix our udc driver.


> What do you think about the problem of stalling the bulk-out endpoint when 
> the host sends too much data?  Maybe this hasn't caused you any 
> difficulty yet.  The problem is that there's a race.  If we call 
> fsg_set_halt() after the host has finished sending all its data, then the 
> host won't see the stalled endpoint and so it won't clear the halt.  My 
> feeling is that fsg should always use the "no-stall" option for data-out 
> transfers, how do you feel?

Yes it have give us problems... I was involve with the last discussion
about this topic, but my knowledge about the bulk-only protocol was very
poor at that time, so I stay out of the conversation.
I understand a bit better now, and I agree that the driver should be
stall free for out transfers.

Thank for your help



-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to