On Friday 27 March 2009, Sergei Shtylyov wrote: > > There is an important issue with such transfers, especially on > > the host side: when such transfers end with a full-size packet, > > we must defer musb_dma_completion() calls until the FIFO empties. > > Sigh, again I'm seeing that you've spoiled my patch description... and > that's after I have once requested you to stop doing such things! :-/ And after I've requested that you provide *concise* descriptions of your patches, instead of ones that are obstacles to review and to understanding what's going on. If you did that more often, you'd have less to complain about. When your summaries are that troublesome, be prepared to see them changed. A few hints as to what that means: (a) Don't focus so much on the low level mechanisms. We all get that such things are important, can be annoying to sort out; been there, done that, you have our sympathy. (b) Patch descriptions should usually be high enough level that readers do not need to be down'n'dirty with the hardware to understand the key issue being addressed. (c) Treat it like the management summary it really is. Bullet points can help, ditto outlines. Long-winded paragraphs of prose are trouble. Shorter is better, within reason. (d) Remember the patch itself provides the real details. The patch comment is just an overview/summary/intro. The original of $SUBJECT had two paragraphs, sixteen and twelve long (!!) lines respectively. Until you get better at being concise, I suggest you avoid paragraphs over, say, five lines of 65 characters each. And also avoid ellipsis instead of real sentence endings. > The size of the last packet totally doesn't matter here! We must react on > the interrupt on TxPktRdy being cleared, not on the DMA completion interrupt, > whatever the size of the last packet is. That's what the patch was about! And when you up-level that ... TXPKTRDY clear == fifo emptying. That size-of-last-packet scenario was the first one detailed in your original patch description, note. I think you've just shown one of the ways your description was unclear. -- 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