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
