On Sun, Nov 25, 2001, Matthew Dharm <[EMAIL PROTECTED]> wrote: > On Sun, Nov 25, 2001 at 12:43:22PM -0800, David Brownell wrote: > > Actually my current thought is that the bulk queuing ought > > to have those exact semantics ... and it's such "fault" handling > > that's exactly where I mentioned (privately) that I see the > > problems coming, similarly on the write side and in terms > > of cancellation. I don't think our HCs do that "right", either > > in the spec sense (see next) or the pragmatic "code does > > reasonable things" sense (consider your scenario). > > See, then I can compose a counter-scenario. > > Consider the following: usb-storage wants to send 3 "transactions" to a > device. A bulk-out command, a bulk-in/out for data, and a bulk-in for > status. Can I queue all these up?
Yes, using ->next. > If the short-transfer on data causes all URBs to stop, then the status is > never transferred. Umm, that's not what would happen. Short packet is not an error if SPD is enabled. It would then progress to the next transfer. If an error does occur, the ->next processing is not done. > If the short-transfer on data does not cause the URBs to stop, then the > status information winds up in the user buffer. Yes, obviously bad situation. > If, however, the HCD understood that the data was a single 'transfer', the > short-packet would properly retire just the data phase and we could > progress to the status phase. It already does do this correctly with ->next. > This is why I want the HCD to understand scatter-gather. It's the only way > that I can get the entire data phase treated as a single transfer, which is > how the model wants to look at it. What you're describing here is not what I would traditionally call scatter-gather. I've always seen scatter-gather split up one logical block of data into multiple physical blocks of data. Like 1 block for an IP header, 1 block for a TCP header and 1 block for the data. It would then send all 3 blocks together as one logical block. You seem to be describing something different with 3 different phases which go to different endpoints (bulk in being different than bulk out). JE _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
