On Tue, May 18, 2010 at 06:36:15AM -0700, Greg KH wrote: > On Tue, May 18, 2010 at 07:20:06AM +0000, darian wrote: > > Thanks Greg > > > > Greg KH <greg@...> writes: > > > Have you tried the 2.6.34 kernel instead? > > > > I've tried 2.6.34-rc7 from sarah and 2.6.34-rc6. the 2.6.34 kernel mainline > > must need the some patches for the function: usb_alloc_streams and > > usb_free_streams etc. > > Ah yes, then you should try the 2.6.35-rc1 release when that happens in > a few weeks, as that will have the stream code. > > > > What does the data show is happening? Perhaps your device really didn't > > > send anything? > > Maybe it is true. But when the stream_id is set to "1" in the host driver. > > The device still get "0xffff" and the NUMP is still "0". I think device won't > > send anything because of this reason. But it made me puzzled "how xhci > > transport these buffer". And the problem becomes why the stream_id changed? > > > > > Do you have a pointer to the source of your driver so we can verify you > > > are setting everything up properly? What type of driver is this? > > > > It is a usb mass storage driver from MCCI. The uasp driver code has been > > submit, which is waiting for your approvement. > > No, it's not waiting for my approval, it got rejected by lots of people > already :) Are you sure you're running an MCCI UAS driver? Synopsis posted a UAS driver to the mailing list, and that did get a lot of feedback (and wasn't accepted for merge by Greg). Matthew Wilcox from Intel also has a UAS driver, and Synopsis was looking at using that. However, I haven't heard anything from MCCI. Where did you get this driver? Sarah Sharp -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
