On Fri, Dec 09, 2011 at 11:35:56AM +0100, Sebastian Andrzej Siewior wrote: > * Sarah Sharp | 2011-12-02 11:55:51 [-0800]: > > >@@ -726,19 +742,28 @@ static int uas_probe(struct usb_interface *intf, const struct usb_device_id *id) > > shost->max_id = 1; > > shost->sg_tablesize = udev->bus->sg_tablesize; > > > >- result = scsi_add_host(shost, &intf->dev); > >- if (result) > >- goto free; > >- shost->hostdata[0] = (unsigned long)devinfo; > >- > > devinfo->intf = intf; > > devinfo->udev = udev; > > uas_configure_endpoints(devinfo); > >+ devinfo->anchors = kmalloc(sizeof(*devinfo->anchors)*devinfo->qdepth, > > xhci_alloc_streams() returns the number of supported stream minus one > for the taken stream 0. Why do you substruct one from qdepth in > uas_slave_configure()? This does not look like 1:1 mapping between > streams <-> scsi command and its urbs. That would be a question for Matthew. I think I remember seeing that the full number of streams possible was one less than it needed to be (with the abort task patch), but I didn't get around to asking him why. > On HS we can only send one command at a time as we have only one stream, > right? But qdepth is set to 256 which makes you here allocate 256 > anchors for only one command at a time. As Alan said, we submit multiple commands at once, and the USB 2.0 device will let us know through the status URB which command it wants to process first. The status URB buffers are all the same size, so we queue one buffer for each command we submit. When we get a status URB back, we may be getting a status for a command that isn't the same as the cmndinfo that is housing the URB status pointer. That's why we can't rely on the context in uas_stat_cmplt, we have to look the command up by tag. And if the device gives us the wrong tag, what do we do in that case? Resubmit the status URB to make sure the number of status URBs and pending commands balance out? We certainly don't know which of the tagged commands the bad tag was for, so we don't know which command to cancel. Probably we should just make the SCSI core reset the device. 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
