On Monday 04 April 2005 1:39 pm, Johannes Berg wrote: > On Mon, 2005-04-04 at 13:22 -0700, David Brownell wrote: > > > > If I pass a URB into the usb layer that has an 81 byte buffer, all those > > > 81 bytes get filled! > > > > Probably the first 64 in one frame, then the last bytes in the next one > > that's polled. That's expected ... otherwise drivers would have some > > very nasty code to handle large interrupt transfers. The policy of > > whether an interrupt URB maps to one frame or N is up to the driver, > > not usbcore or any HCD. > > Hm. I don't quite understand what you're trying to say. Just to be clear > on the issue: I do get blocks of 81 bytes from the device, over and > over. If I tell the kernel I want 81 in one go, it gives me 81 as a > response to a single URB. If I tell the kernel I want just 64, it gives > me 64 in the first URB response and 17 in the second, then 64 again etc.
That's exactly as I described. 64 bytes in one packet, 17 in the next. You are NOT getting 81 bytes in one frame/packet!! > I suppose if I told the kernel I want 40 bytes it'd give me 40, then 40 > and then 1, after which the cycle would restart. No, it should give you 40 bytes with an -EOVERFLOW error since the device sent 64 bytes in that packet. Then probably 17 in the next. > Now, I don't really care in what blocks my driver gets those 81 bytes, > is it be correct to just tell the core usb layer that I want 81 bytes > and rely on it to fill an 81 byte buffer, regardless of how the actual > transfer looks like? If the two reports always go together, and there are no cases where you'd be getting a 64 byte (maxpacket sized) report followed by nothing for many frames ... yes. - Dave ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel