kernelnewbies.kernelnewbies.org archive mirror
 help / color / mirror / Atom feed
From: hugo@carfax.org.uk (Hugo Mills)
To: kernelnewbies@lists.kernelnewbies.org
Subject: Trial Patch
Date: Tue, 9 Sep 2014 22:33:12 +0100	[thread overview]
Message-ID: <20140909213312.GD5783@carfax.org.uk> (raw)
In-Reply-To: <540F6E23.9090508@gmail.com>

On Tue, Sep 09, 2014 at 05:16:19PM -0400, nick wrote:
> 
> 
> On 14-09-09 12:40 PM, Valdis.Kletnieks at vt.edu wrote:
> > On Tue, 09 Sep 2014 11:52:20 -0400, Nick Krause said:
> > 
> >> I understand that , sorry Guys. I am going to fix this later including
> >> my spell checks.
> > 
> > Don't bother.
> > 
> Valdis,
> I am sending this in again fixed and working. I also looked at your complain about write_nic_byte and this 
> seems to be there if this succeeds.

   You've *still* got the spelling errors in there. This is a symptom
of the fundamental reason that your reputation is appalling -- you are
sloppy in your work. You miss (or ignore) details, even small easy
ones like fixing up the capitalisation of NULL and the spelling on the
same line. This sloppiness extends to not understanding the code
you're trying to change, not thinking it through, not compiling it
before it goes out, not testing it properly before it goes out.

   Concentrate on the details. There are lots of details, and you need
to get them *all* right. If someone like Valdis says "you need to fix
this, this and this", fix *everything*. Print out the email, use a
highlighter pen to indicate everything that needs fixing. Put a tick
by every item when you've dealt with it. Don't even *think* about
posting a new revision unless you've got a tick next to every single
highlighter mark.

   If someone asks you a question, like "what happens if the condition
in $line_number is true?", this is intended to make you stop and
think. The questions are leading ones, and are trying to make you see
for yourself why there is a problem in your code. The way things are
at the moment, if you look at one of those questions, and answer it,
and the answer *isn't* "<this> bad thing will happen", then you've
missed the point of the question, and you need to look at it harder.
Not answering the question is not an option at this point.

   Hugo.

> Nick

> >From 1d6378589ab97cc646e2a3717413077453e4e80b Mon Sep 17 00:00:00 2001
> From: Nicholas Krause <xerofoify@gmail.com>
> Date: Mon, 8 Sep 2014 21:30:37 -0400
> Subject: [PATCH] staging: Fix Null check for allocating skb in r8192E_firmware.c
> 
> 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,
> clean up and dequeune the skb quenue. In additon return false
> 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.
> Signed-off-by: Nicholas Krause <xerofoify@gmail.com>
> ---
>  drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c b/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
> index 1a95d1f..6988e1c 100644
> --- a/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
> +++ b/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
> @@ -36,7 +36,6 @@ static bool fw_download_code(struct net_device *dev, u8 *code_virtual_address,
>  			     u32 buffer_len)
>  {
>  	struct r8192_priv *priv = rtllib_priv(dev);
> -	bool		    rt_status = true;
>  	u16		    frag_threshold;
>  	u16		    frag_length, frag_offset = 0;
>  	int		    i;
> @@ -61,6 +60,10 @@ static bool fw_download_code(struct net_device *dev, u8 *code_virtual_address,
>  		}
>  
>  		skb  = dev_alloc_skb(frag_length + 4);
> +		if (skb == NULL) {
> +				skb_queue_purge(&priv->rtllib->skb_waitQ[TXCMD_QUEUE]);
> +				return false;
> +		}
>  		memcpy((unsigned char *)(skb->cb), &dev, sizeof(dev));
>  		tcb_desc = (struct cb_desc *)(skb->cb + MAX_DEV_ADDR_SIZE);
>  		tcb_desc->queue_index = TXCMD_QUEUE;
> @@ -99,7 +102,7 @@ static bool fw_download_code(struct net_device *dev, u8 *code_virtual_address,
>  
>  	write_nic_byte(dev, TPPoll, TPPoll_CQ);
>  
> -	return rt_status;
> +	return true;
>  }
>  
>  static bool CPUcheck_maincodeok_turnonCPU(struct net_device *dev)

-- 
=== Hugo Mills: hugo at ... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
   --- Comic Sans goes into a bar,  and the barman says, "We don't ---   
                         serve your type here."                          
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: Digital signature
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140909/3dcf5d00/attachment-0001.bin 

  reply	other threads:[~2014-09-09 21:33 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-09  3:08 Trial Patch nick
2014-09-09  4:04 ` Valdis.Kletnieks at vt.edu
2014-09-09 12:22 ` nick
2014-09-09 12:42   ` Sudip Mukherjee
2014-09-09 13:24     ` nick
2014-09-09 13:39       ` Sudip Mukherjee
2014-09-09 13:26   ` Valdis.Kletnieks at vt.edu
2014-09-09 13:45 ` Greg Freemyer
2014-09-09 13:54   ` Peter Senna Tschudin
2014-09-09 15:52     ` Nick Krause
2014-09-09 16:40       ` Valdis.Kletnieks at vt.edu
2014-09-09 21:16         ` nick
2014-09-09 21:33           ` Hugo Mills [this message]
2014-09-09 22:03           ` Valdis.Kletnieks at vt.edu
2014-09-10  1:21             ` nick
2014-09-10  2:52               ` Valdis.Kletnieks at vt.edu
2014-09-10  2:56                 ` nick
2014-09-10  3:07                   ` Valdis.Kletnieks at vt.edu
2014-09-10  3:11                     ` nick
2014-09-10  3:53                       ` nick
2014-09-10  4:49                         ` Valdis.Kletnieks at vt.edu
2014-09-10 11:26                           ` nick
2014-09-10 11:36                             ` Hugo Mills
2014-09-10 11:38                             ` Kristofer Hallin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140909213312.GD5783@carfax.org.uk \
    --to=hugo@carfax.org.uk \
    --cc=kernelnewbies@lists.kernelnewbies.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).