On Tue, Dec 27, 2016 at 03:56:11PM +0000, Raz Manor wrote: > I'm not entirely sure either, that is why I wanted the specs. > Alan sent me the PLX NET2280 specs, but I'm using the USB3380/USB3381 - the > USB3 version of the device. > As it seems from the code, the HW interface is mostly the same, with some > minor changes, so it is the same driver (net2280.c) but with some branches > for USB3380 when needed. > Maybe the problem has something to do with a minor difference between the > NET2280 and USB3380, that was over looked when adding the support for the > USB3380. > So, if any of you have the specs for that one, I would love to get them and > see if there is such a difference in that area. > > Anyway, as for the proposed path, this was my logic: > 1. The req->td->dmadesc equals to 0 iff: > -- There was a transaction ending with a short packet, and > -- The read() to read it was shorter than the transaction length, and > -- The read() to complete it is longer than the residue. > I believe this is true from the printouts of various cases, but I can't > be positive it is correct. > > 2. Entering this if, there should be no more data in the endpoint (a short > packet terminated the transaction). If there is, the transaction wasn't > really done and we should exit and wait for it to finish entirely. That is > the inner if. > That inner if should never happen, but it is there to be on the safe > side. That is why it is marked with the comment /* paranoia */. > The size of the data available in the endpoint is ep->dma->dmacount and > it is read to tmp. > This entire clause is based on my own educated guesses. > > 3. If we passed that inner if without breaking in the original code, than tmp > & DMA_BYTE_MASK_COUNT== 0. > That means we will always pass dma bytes count of 0 to dma_done(), > meaning all the requested bytes were read. > > 4. dma_done() reports back to the upper layer that the request (read()) was > done and how many bytes were read. In the original code that would always be > the request size, regardless of the actual size of the data. > That did not make sense to me at all. > > 5. However, the original value of tmp is req->td->dmacount, which is the > dmacount value when the request's dma transaction was finished. And that is a > much more reasonable value to report back to the caller. > > As you can see, this is based a lot on educated guesses and debug printouts > of various cases. That is why I would like to get your input on this, to make > sure I'm on the right track. > > To recreate the problem., try reading from a bulk out endpoint in a loop, > 1024 * n bytes in each iteration. Connect the PLX to a host you can control, > and send to that endpoint 1024 * n +x bytes such that 0 < x < 1024 * n and > (x % 1024) != 0 > You would expect the first read() to return 1024 * n and the second read to > return x, but you will get the first read to return 1024 *n and the second > one to return 1024 * n. > That is true for every positive integer n. > > My patch, solves the problem, and does not break any of the other cases I've > tried. > > To conclude: > I would love to get your input on this patch, as it is based on personal > debugging and guesses, without knowing the HW specs. > I would also love to get the USB3380 specs, so I could verify some aspects of > this problem myself, and for future references.
What ever happened to this? Alan, any thoughts about this change? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
