On Wed, Oct 17, 2012 at 11:39:17AM -0700, Yuliya T wrote: > Hi Sarah, > > Wanted to check back on this previous report: is this a fundamental > bug in the hardware or can there be a workaround in the XHCI driver to > support this? I did find that if the control transfers are 512B in > length (instead of 1024, 2048, or 4096), the host controller doesn't > fail for these transactions. It sounds like a fundamental hardware bug, and I'm not sure how we can work around it. We could pad the control transfers, and change the wLength field, but I think that would break other devices. So that work-around is probably out. Perhaps it would help if the xHCI driver broke the control transfer data phase into multiple chained TRBs, that are a multiple of 512 bytes? E.g. one 1024 byte TRB, followed by a 64 byte TRB. That might help the host controller get the hint that it needs to increment the sequence number. The patch would go something like this: 1. Add a quirk for AsMedia hosts that sets a new xhci->quirks flag in xhci-pci.c. 2. Change xhci-ring.c:xhci_queue_ctrl_tx() to look for the quirk, and calculate how many TRBs we need to make a multiple of 512 bytes, and increment num_trbs accordingly. 3. Make the code in xhci_queue_ctrl_tx() that queues data TRBs queue one data TRB, set the chain bit, and chain one or more normal TRBs to the data TRB. Clear the chain bit on the last normal TRB. I'm not sure when I'll have time to work on this patch, so please take a stab at it if you have some time. The cancellation code might need some work to handle multi-TRB data phases as well, but we shouldn't worry about that until we see if this work-around helps the AsMedia host. Sarah Sharp > On Tue, Oct 2, 2012 at 5:23 PM, Yuliya T <yuliyat001@xxxxxxxxx> wrote: > > We ran into a problem when using ASMedia Technology Inc. ASM1042 > > SuperSpeed USB Host Controller (integrated on the desktop's > > motherboard) with Linux xHCI driver. The host is sending the > > SuperSpeed device a large control transfer (>512B) that requires > > multiple OUT transactions. The first OUT Txn is acknowledged, but > > then the subsequent one is sent by the host with the same sequence > > number. I am attaching a protocol analysis trace (taken with the > > Beagle 5000 SuperSpeed Protocol Analyzer) that illustrates the > > problem. It can be opened with the Total Phase Data Center software: > > http://www.totalphase.com/products/data_center/ > > > > The same interaction with the same device works with an Intel xHCI host. > > > > We are not sure if this is a low-level bug with the ASMedia host or if > > there is some setup/workaround that can be done within the Linux xHCI > > driver to fix this problem. -- 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
