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.
Attachment:
pgpCQWJmudxHL.pgp
Description: PGP signature
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
