Matthew Dharm wrote:
> My only concern is that the behavior be _very_ well defined for this.  I
> can think of all sorts of corner-cases (URBs about to complete, endpoints
> halted, zero-length packets, etc) which all need to be covered before we
> make a change like this.

I'm not clear on what you're saying:

- Are you implying that this change could do more than just
   remove some unneeded failure modes?  (If so, what?)

- Or are you instead implying that the current behavior for
   queued URBs is not defined well enough to suit you?

I can't see how those three cases would be affected.  URBs
about to complete don't need special treatment (any races
inside an HCD must already be addressed); endpoints can't be
submitted to halted endpoints in any case; and insisting on a
"short packet" (by maybe adding a zero length one) at the end
of a transfer is a per-urb characteristic in any case.

- Dave


> Matt
> 
> On Thu, Jun 06, 2002 at 12:41:54PM -0700, David Brownell wrote:
> 
>>In the interest of de-complicating the API and code,
>>I wonder how folk would react to removing the flag
>>that enables bulk queuing ... doing it as needed but
>>without needing an explicit request.
>>
>>How it works today:  when the UHCI drivers find a
>>bulk URB being submitted to an endpoint that already
>>has an URB queued, they check that flag and report
>>an error if it's not set.
>>
>>Since any device driver knows (had better!) that it's
>>doing that, the flag doesn't really add value.  All
>>it does is create error paths within device drivers
>>and HCDs.  (The UHCIs do some magic to deal with the
>>case, but won't kick it in unless that flag is set
>>AND it's needed.)
>>
>>I'd like to hear justifications for keeping that flag
>>around, which would make it worthwhile to keep it.
>>Otherwise I suspect I'll prepare a patch at some point
>>that'll just make the 2.5.* UHCIs not care about it.
>>
>>- Dave
>>
>>
>>_______________________________________________________________
>>
>>Don't miss the 2002 Sprint PCS Application Developer's Conference
>>August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
>>
>>_______________________________________________
>>[EMAIL PROTECTED]
>>To unsubscribe, use the last form field at:
>>https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
> 
> 




_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to