I think in this case, it will take more for silicon not follow
the spec. They can simply reuse the TD fetching unit.
You got a point that new behavior havn't been test widely yet.
Here is the update version of the patch.
Cheers,
Chris
===== devio.c 1.9 vs edited =====
--- 1.9/drivers/usb/devio.c Thu Apr 18 05:34:31 2002
+++ edited/devio.c Wed Feb 5 07:15:23 2003
@@ -800,7 +800,7 @@
return -EINVAL;
}
/* min 8 byte setup packet, max arbitrary */
- if (uurb.buffer_length < 8 || uurb.buffer_length > PAGE_SIZE)
+ if (uurb.buffer_length < 8 || (uurb.buffer_length >> 16))
return -EINVAL;
if (!(dr = kmalloc(sizeof(devrequest), GFP_KERNEL)))
return -ENOMEM;
===== usb-ohci.c 1.23 vs edited =====
--- 1.23/drivers/usb/usb-ohci.c Tue Apr 30 22:58:55 2002
+++ edited/usb-ohci.c Thu Feb 6 13:32:23 2003
@@ -1419,12 +1419,14 @@
urb->setup_packet, 8,
PCI_DMA_TODEVICE),
8, urb, cnt++);
- if (data_len > 0) {
- info = usb_pipeout (urb->pipe)?
- TD_CC | TD_R | TD_DP_OUT | TD_T_DATA1 : TD_CC
| TD_R | TD_DP_IN | TD_T_DATA1;
- /* NOTE: mishandles transfers >8K, some >4K */
- td_fill (ohci, info, data, data_len, urb, cnt++);
- }
+ info = usb_pipeout (urb->pipe)? (TD_CC | TD_R | TD_DP_OUT)
+ : (TD_CC | TD_R | TD_DP_IN);
+ while(data_len > 0) {
+ int td_size = min(4096, data_len);
+ td_fill (ohci, info|(cnt==1? TD_T_DATA1:TD_T_TOGGLE),
+ data, td_size, urb, cnt);
+ data += td_size; data_len -= td_size; cnt++;
+ }
info = usb_pipeout (urb->pipe)?
TD_CC | TD_DP_IN | TD_T_DATA1: TD_CC | TD_DP_OUT |
TD_T_DATA1;
td_fill (ohci, info, data, 0, urb, cnt++);
On Thu, Feb 06, 2003 at 08:19:38PM -0800, David Brownell wrote:
> Hi,
>
> >I think the beginning of the transaction is that 8 byte
> >setup TD, which already reset to DATA0. The (optional) follow
> >up data TD start at the second TD, (if any). Since they are pointed
> >by the same ED, I guess the data TD should be able to using toggle
> >bit, which was reseted by the first setup TD?
>
> With all the different versions of OHCI silicon around, this is
> a case where I'd say "better safe than sorry". That may just
> be paranoia, but on the other hand we _know_ all the current
> "works with Linux" silicon works with DATA1 there today, and
> there's no need to change it.
>
>
> >Should I force to reset the first data TD (which is the second TD in
> >the whole transaction) to use DATA1 then do toggle for the rest of
> >data TD?
>
> That's how I'd do it -- so your update is only to support more
> data stage TDs, not in how the first (and usually only) one of
> them gets initialized.
>
> - Dave
>
>
>
>
>
>
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
