I am attaching a trial patch again , please let me known if there are any issues for me to fix. Nick
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.
On Tue, Sep 09, 2014 at 08:22:59AM -0400, nick wrote:
On 14-09-08 11:08 PM, nick wrote:
I am attaching a trial patch again , please let me known if there are any issues for me to fix. Nick
This patch is wrong, checkpatch errors. I am attaching another fixed version. Sorry 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.
lots of spelling mistake .. what is NuLl ?
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_dequeue(&priv->rtllib->skb_waitQ[TXCMD_QUEUE]);
again checkpatch warning of line over 80 char
+ 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) -- 1.9.1
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
On 14-09-09 08:42 AM, Sudip Mukherjee wrote:
On Tue, Sep 09, 2014 at 08:22:59AM -0400, nick wrote:
On 14-09-08 11:08 PM, nick wrote:
I am attaching a trial patch again , please let me known if there are any issues for me to fix. Nick
This patch is wrong, checkpatch errors. I am attaching another fixed version. Sorry 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.
lots of spelling mistake .. what is NuLl ?
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_dequeue(&priv->rtllib->skb_waitQ[TXCMD_QUEUE]);
again checkpatch warning of line over 80 char
+ 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) -- 1.9.1
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Thanks for the feedback, Guys. I will look over this latter and try and fix it. Nick
On Tue, Sep 9, 2014 at 6:54 PM, nick <xerofoify@gmail.com> wrote:
On 14-09-09 08:42 AM, Sudip Mukherjee wrote:
On Tue, Sep 09, 2014 at 08:22:59AM -0400, nick wrote:
On 14-09-08 11:08 PM, nick wrote:
I am attaching a trial patch again , please let me known if there are any issues for me to fix. Nick
This patch is wrong, checkpatch errors. I am attaching another fixed version. Sorry 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.
lots of spelling mistake .. what is NuLl ?
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_dequeue(&priv->rtllib->skb_waitQ[TXCMD_QUEUE]);
again checkpatch warning of line over 80 char
+ 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) -- 1.9.1
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Thanks for the feedback, Guys. I will look over this latter and try and fix it. Nick
form the very beginning everyone is asking you to check your patch with checkpatch and build test it before submitting .. but .. :( if you are planning to send another patch, can you please include your checkpatch report in the mail , that will save many people's time over here . thanks sudip
On September 8, 2014 11:08:46 PM EDT, nick <xerofoify@gmail.com> wrote:
I am attaching a trial patch again , please let me known if there are any issues for me to fix. Nick
Nick, I guess you know this list is a training ground for the main lists. As such the same rules are enforced when it comes to formatting. Patches as an attachment are simply not acceptable. You have to do them inline. I'm surprised people are even opening your attachments to look at them. Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
On Tue, Sep 9, 2014 at 3:45 PM, Greg Freemyer <greg.freemyer@gmail.com> wrote:
On September 8, 2014 11:08:46 PM EDT, nick <xerofoify@gmail.com> wrote:
I am attaching a trial patch again , please let me known if there are any issues for me to fix. Nick
Nick, I guess you know this list is a training ground for the main lists. As such the same rules are enforced when it comes to formatting.
Patches as an attachment are simply not acceptable. You have to do them inline. I'm surprised people are even opening your attachments to look at them.
My understanding is that the problem is not with attachments, but with using strange things like base64 for attachments. Nick has used plain text attachment which seem perfectly fine for me. Check this: http://www.tux.org/lkml/ "If I get a patch in an attachment (other than a "Text/PLAIN" type attachment with no mangling and that pretty much all mail readers and all tools will see as a normal body), I simply WILL NOT apply it unless I have strong reason to. I usually wont even bother looking at it, unless I expected something special from the sender. Really. Don't send patches as attachments. Linus" So plain text attachment seem to be acceptable...
Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- Peter
On Tue, Sep 9, 2014 at 9:54 AM, Peter Senna Tschudin <peter.senna@gmail.com> wrote:
On Tue, Sep 9, 2014 at 3:45 PM, Greg Freemyer <greg.freemyer@gmail.com> wrote:
On September 8, 2014 11:08:46 PM EDT, nick <xerofoify@gmail.com> wrote:
I am attaching a trial patch again , please let me known if there are any issues for me to fix. Nick
Nick, I guess you know this list is a training ground for the main lists. As such the same rules are enforced when it comes to formatting.
Patches as an attachment are simply not acceptable. You have to do them inline. I'm surprised people are even opening your attachments to look at them.
My understanding is that the problem is not with attachments, but with using strange things like base64 for attachments. Nick has used plain text attachment which seem perfectly fine for me. Check this:
"If I get a patch in an attachment (other than a "Text/PLAIN" type attachment with no mangling and that pretty much all mail readers and all tools will see as a normal body), I simply WILL NOT apply it unless I have strong reason to. I usually wont even bother looking at it, unless I expected something special from the sender.
Really. Don't send patches as attachments.
Linus"
So plain text attachment seem to be acceptable...
Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- Peter I understand that , sorry Guys. I am going to fix this later including my spell checks.
On 14-09-09 12:40 PM, Valdis.Kletnieks@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. Nick
On Tue, Sep 09, 2014 at 05:16:19PM -0400, nick wrote:
On 14-09-09 12:40 PM, Valdis.Kletnieks@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@... 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."
On Tue, 09 Sep 2014 17:16:19 -0400, nick said:
I am sending this in again fixed and working.
Typos are still there, and zero explanation of how you verified "fixed and working", which given your track record of failing to even compile test your code is a *big* show-stopper. If you don't care about your patch enough to even bother fixing the typos, why should anybody else care?
I also looked at your complain about write_nic_byte and this seems to be there if this succeeds.
OK. This is C 101. How does write_nic_byte() get called if we just did the 'return false' and left both the do/while loop and the entire function in your patch?
On 14-09-09 06:03 PM, Valdis.Kletnieks@vt.edu wrote:
On Tue, 09 Sep 2014 17:16:19 -0400, nick said:
I am sending this in again fixed and working.
Typos are still there, and zero explanation of how you verified "fixed and working", which given your track record of failing to even compile test your code is a *big* show-stopper.
If you don't care about your patch enough to even bother fixing the typos, why should anybody else care?
I also looked at your complain about write_nic_byte and this seems to be there if this succeeds.
OK. This is C 101. How does write_nic_byte() get called if we just did the 'return false' and left both the do/while loop and the entire function in your patch?
Not going to execute, I wasn't sure if that statement needs to be executed. Seems it needs to be for the driver to be activated. Thanks for helping out with my sloppiness :) and being patience. If there are any more problems let me known. Nick
On Tue, 09 Sep 2014 21:21:18 -0400, nick said:
Not going to execute, I wasn't sure if that statement needs to be executed.
skb = dev_alloc_skb(frag_length + 4); + if (skb == NULL) { + skb_queue_purge(&priv->rtllib->skbwaitQ[TXCMD_QUEUE]; + break; + } OK. It's official. I see *zero* possibility that you'll ever manage to write an acceptable patch. This is *still* wrong.
On 14-09-09 10:52 PM, Valdis.Kletnieks@vt.edu wrote:
On Tue, 09 Sep 2014 21:21:18 -0400, nick said:
Not going to execute, I wasn't sure if that statement needs to be executed.
skb = dev_alloc_skb(frag_length + 4); + if (skb == NULL) { + skb_queue_purge(&priv->rtllib->skbwaitQ[TXCMD_QUEUE]; + break; + }
OK. It's official. I see *zero* possibility that you'll ever manage to write an acceptable patch. This is *still* wrong.
Care to explain. Nick
On 14-09-09 11:07 PM, Valdis.Kletnieks@vt.edu wrote:
On Tue, 09 Sep 2014 22:56:10 -0400, nick said:
OK. It's official. I see *zero* possibility that you'll ever manage to write an acceptable patch. This is *still* wrong.
Care to explain.
No. Please go figure it out for yourself.
I think I fixed it through. If not I known why. Nick
On 14-09-09 11:11 PM, nick wrote:
On 14-09-09 11:07 PM, Valdis.Kletnieks@vt.edu wrote:
On Tue, 09 Sep 2014 22:56:10 -0400, nick said:
OK. It's official. I see *zero* possibility that you'll ever manage to write an acceptable patch. This is *still* wrong.
Care to explain.
No. Please go figure it out for yourself.
I think I fixed it through. If not I known why. Nick
Sorry Valdis, Build Error. Fixed it. I need to really check my patches first :(. In addition, I want you to forget about and not reply to any patches you known I haven't build tested. Nick
On Tue, 09 Sep 2014 23:53:50 -0400, nick said:
Build Error. Fixed it. I need to really check my patches first :(.
How many times have you done that now?
In addition, I want you to forget about and not reply to any patches you known I haven't build tested.
No, it doesn't work like that. Each broken post counts against you.
+ if (skb == NULL) { + skb_queue_purge(&priv->rtllib->skb_waitQ[TXCMD_QUEUE]); + break; + }
Like this one - it's *still* wrong. Because.... From: Nicholas Krause <xerofoify@gmail.com> Date: Tue, 9 Sep 2014 21:12:56 -0400 You reposted the same broken patch again. Please do the Linux kernel community a favor and seek gainful employment in the food service industry or similar, where your skills will be more appreciated.
On 14-09-10 12:49 AM, Valdis.Kletnieks@vt.edu wrote:
On Tue, 09 Sep 2014 23:53:50 -0400, nick said:
Build Error. Fixed it. I need to really check my patches first :(.
How many times have you done that now?
In addition, I want you to forget about and not reply to any patches you known I haven't build tested.
No, it doesn't work like that. Each broken post counts against you.
+ if (skb == NULL) { + skb_queue_purge(&priv->rtllib->skb_waitQ[TXCMD_QUEUE]); + break; + }
Like this one - it's *still* wrong. Because....
From: Nicholas Krause <xerofoify@gmail.com> Date: Tue, 9 Sep 2014 21:12:56 -0400
You reposted the same broken patch again.
Please do the Linux kernel community a favor and seek gainful employment in the food service industry or similar, where your skills will be more appreciated.
Here is the correct patch. Nick
On Wed, Sep 10, 2014 at 07:26:32AM -0400, nick wrote:
On 14-09-10 12:49 AM, Valdis.Kletnieks@vt.edu wrote: [snip]
Like this one - it's *still* wrong. Because....
From: Nicholas Krause <xerofoify@gmail.com> Date: Tue, 9 Sep 2014 21:12:56 -0400
You reposted the same broken patch again. [snip] Here is the correct patch. Nick
From ad55b627241203a380dd9c708a4feae98446f85f Mon Sep 17 00:00:00 2001 From: Nicholas Krause <xerofoify@gmail.com> Date: Tue, 9 Sep 2014 21:12:56 -0400 Subject: [PATCH] staging: Fix NULL check for allocating the skb in r8192E_firmware.c
This patch checks in the loop of the function, fw_download_code if a allocated skb is NULL. If the skb is NULL then we first free the allocated skbs in the queue of this function with skb_queue_purge in order to free the allocated skbs. After the freeing of the queue we break out of the do/while of this function as we need to run write_nic_byte in order to activate parts of the network card's driver.
Signed-off-by: Nicholas Krause <xerofoify@gmail.com> --- drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c b/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c index 1a95d1f..a251414 100644 --- a/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c +++ b/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c @@ -61,6 +61,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]); + break; + } 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;
I'll save Valdis the trouble here. This is still wrong. It's *identical* to the last one you sent. Bit for bit. Again, you've lost track of even the most fundamental details ("Am I sending the thing I wanted to?") Doing this once or twice, occasionally, is OK. Everyone makes mistakes every so often. Doing it repeatedly, on a nearly daily basis, over a period of a couple of months, is simply unacceptable. Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- Our so-called leaders speak/with words they try to jail ya/ --- They subjugate the meek/but it's the rhetoric of failure.
This is exactly the same patch as you sent last time. And it's still wrong. Nick, just out of curiosity: How old are you? On Wed, Sep 10, 2014 at 1:26 PM, nick <xerofoify@gmail.com> wrote:
On 14-09-10 12:49 AM, Valdis.Kletnieks@vt.edu wrote:
On Tue, 09 Sep 2014 23:53:50 -0400, nick said:
Build Error. Fixed it. I need to really check my patches first :(.
How many times have you done that now?
In addition, I want you to forget about and not reply to any patches you known I haven't build tested.
No, it doesn't work like that. Each broken post counts against you.
+ if (skb == NULL) { + skb_queue_purge(&priv->rtllib->skb_waitQ[TXCMD_QUEUE]); + break; + }
Like this one - it's *still* wrong. Because....
From: Nicholas Krause <xerofoify@gmail.com> Date: Tue, 9 Sep 2014 21:12:56 -0400
You reposted the same broken patch again.
Please do the Linux kernel community a favor and seek gainful employment in the food service industry or similar, where your skills will be more appreciated.
Here is the correct patch. Nick
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
participants (8)
-
Greg Freemyer -
Hugo Mills -
Kristofer Hallin -
nick -
Nick Krause
-
Peter Senna Tschudin -
Sudip Mukherjee -
Valdis.Kletnieks＠vt.edu