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
