David Brownell 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.
Maybe the obstacle is just on your side?
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.
It was the first case in my several years open soucre tenure that somebody
just completely rewrote my patch description, and what was the result? It was
ruined as the rewriter decided to drop the validly described main reason of
kernel oops and instead put in 2 non-reasons. I think it was totally the
rewriter's fault, not mine.
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.
I'm describing the technical details for exactly the better understadning,
not because I need anyone's sympathy. If I permit myself to be a bit windy,
that's more to entertain the reader, so to speak.
(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.
Sigh. If the issue was simple, the descriptio would have been short. But
in this case there were several issues, not one even.
(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.
Sorry, I thought I communicate with programmers, not the management. :-D
(d) Remember the patch itself provides the real details. The
patch comment is just an overview/summary/intro.
It depends on the patch. If I'll be short in the description, some people
will complain that the patch isn't well described.
The original of $SUBJECT had two paragraphs, sixteen and twelve
long (!!) lines respectively.
If you have so much trouble parsing complex sentenses -- well, perhaps you
just shouldn't have missed classes.
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.
Stop teaching me already. I'm not in a school and you're not a teacher. To
say the truth, your patches have never served as good examples to me, so
you're just not authoritative enough for me to just listen with my mouth open
and scribble down after you.
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.
OK, I probably needed to swap these two sentenses. But you've just made it
worse by almost completely dropping the description of the main CPPI scenario
that was patch was about. And that certainly wasn't my fault.
WBR, Sergei
--
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
