Trial Patch

[Valdis.Kletnieks@vt.edu (Valdis.Kletnieks at vt.edu)]

On Mon, 08 Sep 2014 23:08:46 -0400, nick said:
> I am attaching a trial patch again , please let me known if there are any issues for me to fix.

Executive summary:  Many.  Most of which you've been told about before.

> This patch checks in fw_download_code for if the allocated skb is
> NULl. Further more if the skb is null and we are in the loop,

Make up your mind regarding how many capital letters 'null' has.

This was mentioned to you earlier today. The proper response is *not* to
come up with yet another variant.

> clean up and dequeune the skb quenue. In additon return false

dequeue, addition.

We do cut some slack for people whose first language isn't English. However, if
you're a native speaker, there's really no excuse for not spell-checking the
changelog.

Remember - nothing screams poor workmanship quite like wrinkles in the duct
tape.

> directly in the if statement and return true by itself removing
> rt_status to improve the code's readablitiy of return statements
> in fw_download_code.

Do one thing per patch.  Especially when you're still trying to convince us
that you're in fact able to do one thing correctly in a patch.

+				skb_dequeue(&priv->rtllib->skb_waitQ[TXCMD_QUEUE]);
+				return false;

You have been told before regarding this patch that this bypasses a call
to write_nic_byte() at the end of the function.  I see zero discussion
of why you consider it safe to do so, nor do I see any indication that
you've researched whether or not skb_dequeue() is sufficient to deal with
cleaning up after a non-initial fragment.

Sorry Nick, but I've pretty much reached the point where any further patch from
you that doesn't fully address already-mentioned review comments (including
general comments on procedure and the like from *other* patches) are going to
be silently tossed into my bit bucket.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140909/061e2323/attachment.bin