staging: ozwpan: Remove redundant null check before kfree in ozpd.c
A message that is not in the archive (sent off-list or not yet received): [email protected]
PATCH v2 1/3 staging: ozwpan: Remove redundant null check before kfree in ozpd.c
Call kfree only if required else return from function.
--- drivers/staging/ozwpan/ozpd.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-)
drivers/staging/ozwpan/ozpd.c +3 -3
@@ -399,11 +399,11 @@ static void oz_tx_frame_free(struct oz_pd *pd, struct oz_tx_frame *f) f->link.next = pd->tx_pool; pd->tx_pool = &f->link; pd->tx_pool_count++; - f =0 ; +spin_unlock_bh (&pd->tx_frame_lock); +return ; }spin_unlock_bh (&pd->tx_frame_lock); -if (f) -kfree (f); +kfree (f); }/*------------------------------------------------------------------------------ * Context: softirq-serialized
Signature · 1 line
1.7.5.4
Quoted 4 lines · Rupesh Gujare
Call kfree only if required else return from function.
Signed-off-by Sachin Kamat <[email protected]>Signed-off-by Rupesh Gujare <[email protected]>
I'm not sure this is right.
Signed-off-by is intended to have a legal meaning that you are signing off that you have permission to submit the patch. You're not allowed to sign off on behalf of someone else.
If we apply this as is, then you get the author credit. If you want to give Sachin author credit then make the first line of the email:
From: Sachin Kamat <[email protected]>
Also it's not a good idea to get too control freaky over this code which is all going to have to be replaced before this can graduate out of staging. You're just going to discourage people from contributing if you redo all their patches. Linaro people are the real deal and you should let them help.
regards,
dan carpenter
Quoted 7 lines · Dan Carpenter
Quoted 4 lines · Rupesh Gujare
Call kfree only if required else return from function.
Signed-off-by Sachin Kamat <[email protected]>Signed-off-by Rupesh Gujare <[email protected]>I'm not sure this is right.
Quoted 8 lines
Signed-off-by is intended to have a legal meaning that you are signing off that you have permission to submit the patch. You're not allowed to sign off on behalf of someone else.
If we apply this as is, then you get the author credit. If you want to give Sachin author credit then make the first line of the email:
From: Sachin Kamat <[email protected]>
All right, thats my mistake. I did not understood "signed-off-by" properly . All my intention was to acknowledge original author's contribution and make changes which are good for driver code. I am more than happy to resend this patch series if I am allowed to use someone else credentials (which I felt is wrong)
Please let me know what is a best way to do it.
Quoted 8 lines
Also it's not a good idea to get too control freaky over this code which is all going to have to be replaced before this can graduate out of staging. You're just going to discourage people from contributing if you redo all their patches. Linaro people are the real deal and you should let them help.
Only intention to redo this patch series is that, new code implemented seems more logical to me. I welcome any criticism of code, & I am very much happy to accept any contributions, as done in past.
Signature · 2 lines
Regards, Rupesh Gujare
When someone sends a patch there are a several possible responses:
1) Ack the patch.
2) Request that the submitter redo it. The downside is that no one likes redoing patches.
3) Reject the patch.
4) Redo it yourself and say "Based on a patch from Sachin Kamat". This isn't nice because everyone wants author credit.
5) Redo it and get permission from the original author to give them author credit get their signed-off-by.
Your version is better, that's not even a question. It's just that now we're in an awkward place and having long discussions about trivial patches that are going to be re-written anyway. :P
regards,
dan carpenter
Quoted 11 lines · Dan Carpenter
When someone sends a patch there are a several possible responses:
1) Ack the patch.
2) Request that the submitter redo it. The downside is that no one likes redoing patches.
3) Reject the patch.
4) Redo it yourself and say "Based on a patch from Sachin Kamat". This isn't nice because everyone wants author credit.
5) Redo it and get permission from the original author to give them author credit get their signed-off-by.
Thanks Dan
I will keep it in mind in future.
Sachin,
Are you interested in redoing (or sending sign-off ?) for this patch series ? I am more than happy to accept either.
Signature · 2 lines
Regards, Rupesh Gujare
Greg KH
maintainerQuoted 12 lines · Rupesh Gujare
Quoted 11 lines · Dan Carpenter
When someone sends a patch there are a several possible responses:
1) Ack the patch.
2) Request that the submitter redo it. The downside is that no one likes redoing patches.
3) Reject the patch.
4) Redo it yourself and say "Based on a patch from Sachin Kamat". This isn't nice because everyone wants author credit.
5) Redo it and get permission from the original author to give them author credit get their signed-off-by.
Quoted 8 lines
Thanks Dan
I will keep it in mind in future.
Sachin,
Are you interested in redoing (or sending sign-off ?) for this patch series ? I am more than happy to accept either.
Don't worry, I'll clean up the mess here...
Quoted 15 lines · Greg KH
Quoted 14 lines · Rupesh Gujare
Quoted 11 lines · Dan Carpenter
When someone sends a patch there are a several possible responses:
1) Ack the patch.
2) Request that the submitter redo it. The downside is that no one likes redoing patches.
3) Reject the patch.
4) Redo it yourself and say "Based on a patch from Sachin Kamat". This isn't nice because everyone wants author credit.
5) Redo it and get permission from the original author to give them author credit get their signed-off-by.Thanks Dan
Quoted 9 lines
Quoted 6 lines
I will keep it in mind in future.
Sachin,
Are you interested in redoing (or sending sign-off ?) for this patch series ? I am more than happy to accept either.
Don't worry, I'll clean up the mess here...
Sorry Greg,
But looks like you applied V1 of this patch series, rather than V2. Is that intentional ?
Below is link for V2 :-
http://driverdev.linuxdriverproject.org/pipermail/devel/2012-November/033339.html
& yes, V2 is missing -
From: Sachin Kamat<[email protected]>
Signature · 2 lines
Regards, Rupesh Gujare
Greg KH
maintainerQuoted 22 lines · Rupesh Gujare
Quoted 21 lines · Greg KH
Quoted 20 lines · Rupesh Gujare
Quoted 11 lines · Dan Carpenter
When someone sends a patch there are a several possible responses:
1) Ack the patch.
2) Request that the submitter redo it. The downside is that no one likes redoing patches.
3) Reject the patch.
4) Redo it yourself and say "Based on a patch from Sachin Kamat". This isn't nice because everyone wants author credit.
5) Redo it and get permission from the original author to give them author credit get their signed-off-by.Thanks Dan
I will keep it in mind in future.
Sachin,
Are you interested in redoing (or sending sign-off ?) for this patch series ? I am more than happy to accept either.
Quoted 7 lines
Quoted 3 lines
Don't worry, I'll clean up the mess here...
Sorry Greg,
But looks like you applied V1 of this patch series, rather than V2. Is that intentional ?
Yes.
You got the authorship version wrong on your set of patches, so I took V1 which correctly handled it.
And, I commented on your one different patch. Please resend anything, based on the patches I took, if you want to see them done differently.
thanks,
greg k-h
v2 cover staging : ozwpan: Remove NULL pointer check
In reply to a message not in the archiveThis patch series removes NULL pointer check before kfree
Rupesh Gujare (3):
staging: ozwpan: Remove redundant null check before kfree in ozpd.c
staging: ozwpan: Remove redundant null check before kfree in
ozproto.c
staging: ozwpan: Remove redundant null check before kfree in ozhcd.c
drivers/staging/ozwpan/ozhcd.c | 6 +++--- drivers/staging/ozwpan/ozpd.c | 6 +++--- drivers/staging/ozwpan/ozproto.c | 6 ++---- 3 files changed, 8 insertions(+), 10 deletions(-)
Signature · 1 line
1.7.5.4
PATCH v2 2/3 staging: ozwpan: Remove redundant null check before kfree in ozproto.c
In reply to a message not in the archiveFree memory if timer pool count > OZ_MAX_TIMER_POOL_SIZE
--- drivers/staging/ozwpan/ozproto.c | 6 ++---- 1 files changed, 2 insertions(+), 4 deletions(-)
drivers/staging/ozwpan/ozproto.c +2 -4
@@ -552,8 +552,8 @@ static void oz_protocol_timer(unsigned long arg) t->link.next = g_timer_pool; g_timer_pool = &t->link; g_timer_pool_count++; - t =0 ; - } + }else +kfree (t);if (!list_empty (&g_timer_list)) { t2 =container_of (g_timer_list.next, struct oz_timer, link);
@@ -566,8 +566,6 @@ static void oz_protocol_timer(unsigned long arg) }spin_unlock_bh (&g_polling_lock);oz_pd_put (pd); -if (t) -kfree (t); t = t2; }while (t); g_timer_state =OZ_TIMER_IDLE ;
Signature · 1 line
1.7.5.4
PATCH v2 3/3 staging: ozwpan: Remove redundant null check before kfree in ozhcd.c
In reply to a message not in the archiveCall kfree only if required else return from function.
--- drivers/staging/ozwpan/ozhcd.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-)
drivers/staging/ozwpan/ozhcd.c +3 -3
@@ -274,12 +274,12 @@ static void oz_free_urb_link(struct oz_urb_link *urbl)if (g_link_pool_size <OZ_MAX_LINK_POOL_SIZE ) { urbl->link.next = g_link_pool; g_link_pool = &urbl->link; - urbl =0 ; g_link_pool_size++; +spin_unlock_irqrestore (&g_link_lock, irq_state); +return ; }spin_unlock_irqrestore (&g_link_lock, irq_state); -if (urbl) -kfree (urbl); +kfree (urbl); } }/*------------------------------------------------------------------------------
Signature · 1 line
1.7.5.4