All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] staging: Fix spacing between function name and parentheses
@ 2014-10-11  1:55 Nicholas Krause
  2014-10-11  4:58 ` Sudip Mukherjee
  0 siblings, 1 reply; 26+ messages in thread
From: Nicholas Krause @ 2014-10-11  1:55 UTC (permalink / raw)
  To: kernelnewbies

Fixes checkpatch coding style warning about unneeded space
between function name an parentheses.

Signed-off-by: Nicholas Krause <xerofoify@gmail.com>
---
Untested
 drivers/staging/octeon-usb/octeon-hcd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/octeon-usb/octeon-hcd.c b/drivers/staging/octeon-usb/octeon-hcd.c
index 5f9db4c..bbeb0cc 100644
--- a/drivers/staging/octeon-usb/octeon-hcd.c
+++ b/drivers/staging/octeon-usb/octeon-hcd.c
@@ -412,7 +412,7 @@ struct octeon_hcd {
 		type c;							    \
 		while (1) {						    \
 			c.u32 = __cvmx_usb_read_csr32(usb, address);	    \
-			if (c.s.field op (value)) {			    \
+			if (c.s.field op(value)) {			    \
 				result = 0;				    \
 				break;					    \
 			} else if (cvmx_get_cycle() > done) {		    \
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 26+ messages in thread

* [PATCH] staging: Fix spacing between function name and parentheses
  2014-10-11  1:55 [PATCH] staging: Fix spacing between function name and parentheses Nicholas Krause
@ 2014-10-11  4:58 ` Sudip Mukherjee
  2014-10-11  5:23   ` Dave Tian
  0 siblings, 1 reply; 26+ messages in thread
From: Sudip Mukherjee @ 2014-10-11  4:58 UTC (permalink / raw)
  To: kernelnewbies

On Fri, Oct 10, 2014 at 09:55:48PM -0400, Nicholas Krause wrote:
> Fixes checkpatch coding style warning about unneeded space
> between function name an parentheses.
> 
> Signed-off-by: Nicholas Krause <xerofoify@gmail.com>
> ---
> Untested
>  drivers/staging/octeon-usb/octeon-hcd.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/octeon-usb/octeon-hcd.c b/drivers/staging/octeon-usb/octeon-hcd.c
> index 5f9db4c..bbeb0cc 100644
> --- a/drivers/staging/octeon-usb/octeon-hcd.c
> +++ b/drivers/staging/octeon-usb/octeon-hcd.c
> @@ -412,7 +412,7 @@ struct octeon_hcd {
>  		type c;							    \
>  		while (1) {						    \
>  			c.u32 = __cvmx_usb_read_csr32(usb, address);	    \
> -			if (c.s.field op (value)) {			    \
> +			if (c.s.field op(value)) {			    \

have you read the code before modifying it?
this is not a function.
have you seen how CVMX_WAIT_FOR_FIELD32 is being called?
on every call of CVMX_WAIT_FOR_FIELD32 op is the operator "=="
so when called the macro will be c.s.field == (value).
if your patch is applied then it will become c.s.field ==(value) .. will that be correct ?

thanks
sudip	

>  				result = 0;				    \
>  				break;					    \
>  			} else if (cvmx_get_cycle() > done) {		    \
> -- 
> 1.9.1
> 
> 
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [PATCH] staging: Fix spacing between function name and parentheses
  2014-10-11  4:58 ` Sudip Mukherjee
@ 2014-10-11  5:23   ` Dave Tian
  2014-10-11  6:08     ` Sudip Mukherjee
  0 siblings, 1 reply; 26+ messages in thread
From: Dave Tian @ 2014-10-11  5:23 UTC (permalink / raw)
  To: kernelnewbies

It also works as value is surrounded by (), though I do not think the patch itself is right or useful.

Dave Tian
dave.jing.tian at gmail.com



On Oct 11, 2014, at 12:58 PM, Sudip Mukherjee <sudipm.mukherjee@gmail.com> wrote:

> On Fri, Oct 10, 2014 at 09:55:48PM -0400, Nicholas Krause wrote:
>> Fixes checkpatch coding style warning about unneeded space
>> between function name an parentheses.
>> 
>> Signed-off-by: Nicholas Krause <xerofoify@gmail.com>
>> ---
>> Untested
>> drivers/staging/octeon-usb/octeon-hcd.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/drivers/staging/octeon-usb/octeon-hcd.c b/drivers/staging/octeon-usb/octeon-hcd.c
>> index 5f9db4c..bbeb0cc 100644
>> --- a/drivers/staging/octeon-usb/octeon-hcd.c
>> +++ b/drivers/staging/octeon-usb/octeon-hcd.c
>> @@ -412,7 +412,7 @@ struct octeon_hcd {
>> 		type c;							    \
>> 		while (1) {						    \
>> 			c.u32 = __cvmx_usb_read_csr32(usb, address);	    \
>> -			if (c.s.field op (value)) {			    \
>> +			if (c.s.field op(value)) {			    \
> 
> have you read the code before modifying it?
> this is not a function.
> have you seen how CVMX_WAIT_FOR_FIELD32 is being called?
> on every call of CVMX_WAIT_FOR_FIELD32 op is the operator "=="
> so when called the macro will be c.s.field == (value).
> if your patch is applied then it will become c.s.field ==(value) .. will that be correct ?
> 
> thanks
> sudip	
> 
>> 				result = 0;				    \
>> 				break;					    \
>> 			} else if (cvmx_get_cycle() > done) {		    \
>> -- 
>> 1.9.1
>> 
>> 
>> _______________________________________________
>> Kernelnewbies mailing list
>> Kernelnewbies at kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> 
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [PATCH] staging: Fix spacing between function name and parentheses
  2014-10-11  5:23   ` Dave Tian
@ 2014-10-11  6:08     ` Sudip Mukherjee
  2014-10-11  6:11       ` Dave Tian
  0 siblings, 1 reply; 26+ messages in thread
From: Sudip Mukherjee @ 2014-10-11  6:08 UTC (permalink / raw)
  To: kernelnewbies

Hi Dave,
It will work. But my point of saying that was  c.s.field ==(value) is
again not according to the style.

thanks
sudip

On Sat, Oct 11, 2014 at 10:53 AM, Dave Tian <dave.jing.tian@gmail.com> wrote:
> It also works as value is surrounded by (), though I do not think the patch itself is right or useful.
>
> Dave Tian
> dave.jing.tian at gmail.com
>
>
>
> On Oct 11, 2014, at 12:58 PM, Sudip Mukherjee <sudipm.mukherjee@gmail.com> wrote:
>
>> On Fri, Oct 10, 2014 at 09:55:48PM -0400, Nicholas Krause wrote:
>>> Fixes checkpatch coding style warning about unneeded space
>>> between function name an parentheses.
>>>
>>> Signed-off-by: Nicholas Krause <xerofoify@gmail.com>
>>> ---
>>> Untested
>>> drivers/staging/octeon-usb/octeon-hcd.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/staging/octeon-usb/octeon-hcd.c b/drivers/staging/octeon-usb/octeon-hcd.c
>>> index 5f9db4c..bbeb0cc 100644
>>> --- a/drivers/staging/octeon-usb/octeon-hcd.c
>>> +++ b/drivers/staging/octeon-usb/octeon-hcd.c
>>> @@ -412,7 +412,7 @@ struct octeon_hcd {
>>>              type c;                                                     \
>>>              while (1) {                                                 \
>>>                      c.u32 = __cvmx_usb_read_csr32(usb, address);        \
>>> -                    if (c.s.field op (value)) {                         \
>>> +                    if (c.s.field op(value)) {                          \
>>
>> have you read the code before modifying it?
>> this is not a function.
>> have you seen how CVMX_WAIT_FOR_FIELD32 is being called?
>> on every call of CVMX_WAIT_FOR_FIELD32 op is the operator "=="
>> so when called the macro will be c.s.field == (value).
>> if your patch is applied then it will become c.s.field ==(value) .. will that be correct ?
>>
>> thanks
>> sudip
>>
>>>                              result = 0;                                 \
>>>                              break;                                      \
>>>                      } else if (cvmx_get_cycle() > done) {               \
>>> --
>>> 1.9.1
>>>
>>>
>>> _______________________________________________
>>> Kernelnewbies mailing list
>>> Kernelnewbies at kernelnewbies.org
>>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>
>> _______________________________________________
>> Kernelnewbies mailing list
>> Kernelnewbies at kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [PATCH] staging: Fix spacing between function name and parentheses
  2014-10-11  6:08     ` Sudip Mukherjee
@ 2014-10-11  6:11       ` Dave Tian
  2014-10-11  8:27         ` Peter Senna Tschudin
  0 siblings, 1 reply; 26+ messages in thread
From: Dave Tian @ 2014-10-11  6:11 UTC (permalink / raw)
  To: kernelnewbies

Agreed - that is why I mentioned the patch is neither right nor useful:)

-daveti


On Oct 11, 2014, at 2:08 PM, Sudip Mukherjee <sudipm.mukherjee@gmail.com> wrote:

> Hi Dave,
> It will work. But my point of saying that was  c.s.field ==(value) is
> again not according to the style.
> 
> thanks
> sudip
> 
> On Sat, Oct 11, 2014 at 10:53 AM, Dave Tian <dave.jing.tian@gmail.com> wrote:
>> It also works as value is surrounded by (), though I do not think the patch itself is right or useful.
>> 
>> Dave Tian
>> dave.jing.tian at gmail.com
>> 
>> 
>> 
>> On Oct 11, 2014, at 12:58 PM, Sudip Mukherjee <sudipm.mukherjee@gmail.com> wrote:
>> 
>>> On Fri, Oct 10, 2014 at 09:55:48PM -0400, Nicholas Krause wrote:
>>>> Fixes checkpatch coding style warning about unneeded space
>>>> between function name an parentheses.
>>>> 
>>>> Signed-off-by: Nicholas Krause <xerofoify@gmail.com>
>>>> ---
>>>> Untested
>>>> drivers/staging/octeon-usb/octeon-hcd.c | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>> 
>>>> diff --git a/drivers/staging/octeon-usb/octeon-hcd.c b/drivers/staging/octeon-usb/octeon-hcd.c
>>>> index 5f9db4c..bbeb0cc 100644
>>>> --- a/drivers/staging/octeon-usb/octeon-hcd.c
>>>> +++ b/drivers/staging/octeon-usb/octeon-hcd.c
>>>> @@ -412,7 +412,7 @@ struct octeon_hcd {
>>>>             type c;                                                     \
>>>>             while (1) {                                                 \
>>>>                     c.u32 = __cvmx_usb_read_csr32(usb, address);        \
>>>> -                    if (c.s.field op (value)) {                         \
>>>> +                    if (c.s.field op(value)) {                          \
>>> 
>>> have you read the code before modifying it?
>>> this is not a function.
>>> have you seen how CVMX_WAIT_FOR_FIELD32 is being called?
>>> on every call of CVMX_WAIT_FOR_FIELD32 op is the operator "=="
>>> so when called the macro will be c.s.field == (value).
>>> if your patch is applied then it will become c.s.field ==(value) .. will that be correct ?
>>> 
>>> thanks
>>> sudip
>>> 
>>>>                             result = 0;                                 \
>>>>                             break;                                      \
>>>>                     } else if (cvmx_get_cycle() > done) {               \
>>>> --
>>>> 1.9.1
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Kernelnewbies mailing list
>>>> Kernelnewbies at kernelnewbies.org
>>>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>> 
>>> _______________________________________________
>>> Kernelnewbies mailing list
>>> Kernelnewbies at kernelnewbies.org
>>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>> 

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [PATCH] staging: Fix spacing between function name and parentheses
  2014-10-11  6:11       ` Dave Tian
@ 2014-10-11  8:27         ` Peter Senna Tschudin
  2014-10-11  9:45           ` Sudip Mukherjee
  0 siblings, 1 reply; 26+ messages in thread
From: Peter Senna Tschudin @ 2014-10-11  8:27 UTC (permalink / raw)
  To: kernelnewbies

I think that, in this case, checkpatch.pl contributed:

$ ./scripts/checkpatch.pl -f drivers/staging/octeon-usb/octeon-hcd.c
WARNING: space prohibited between function name and open parenthesis '('
#415: FILE: drivers/staging/octeon-usb/octeon-hcd.c:415:
+                       if (c.s.field op (value)) {                         \


On Sat, Oct 11, 2014 at 8:11 AM, Dave Tian <dave.jing.tian@gmail.com> wrote:
> Agreed - that is why I mentioned the patch is neither right nor useful:)
>
> -daveti
>
>
> On Oct 11, 2014, at 2:08 PM, Sudip Mukherjee <sudipm.mukherjee@gmail.com> wrote:
>
>> Hi Dave,
>> It will work. But my point of saying that was  c.s.field ==(value) is
>> again not according to the style.
>>
>> thanks
>> sudip
>>
>> On Sat, Oct 11, 2014 at 10:53 AM, Dave Tian <dave.jing.tian@gmail.com> wrote:
>>> It also works as value is surrounded by (), though I do not think the patch itself is right or useful.
>>>
>>> Dave Tian
>>> dave.jing.tian at gmail.com
>>>
>>>
>>>
>>> On Oct 11, 2014, at 12:58 PM, Sudip Mukherjee <sudipm.mukherjee@gmail.com> wrote:
>>>
>>>> On Fri, Oct 10, 2014 at 09:55:48PM -0400, Nicholas Krause wrote:
>>>>> Fixes checkpatch coding style warning about unneeded space
>>>>> between function name an parentheses.
>>>>>
>>>>> Signed-off-by: Nicholas Krause <xerofoify@gmail.com>
>>>>> ---
>>>>> Untested
>>>>> drivers/staging/octeon-usb/octeon-hcd.c | 2 +-
>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/staging/octeon-usb/octeon-hcd.c b/drivers/staging/octeon-usb/octeon-hcd.c
>>>>> index 5f9db4c..bbeb0cc 100644
>>>>> --- a/drivers/staging/octeon-usb/octeon-hcd.c
>>>>> +++ b/drivers/staging/octeon-usb/octeon-hcd.c
>>>>> @@ -412,7 +412,7 @@ struct octeon_hcd {
>>>>>             type c;                                                     \
>>>>>             while (1) {                                                 \
>>>>>                     c.u32 = __cvmx_usb_read_csr32(usb, address);        \
>>>>> -                    if (c.s.field op (value)) {                         \
>>>>> +                    if (c.s.field op(value)) {                          \
>>>>
>>>> have you read the code before modifying it?
>>>> this is not a function.
>>>> have you seen how CVMX_WAIT_FOR_FIELD32 is being called?
>>>> on every call of CVMX_WAIT_FOR_FIELD32 op is the operator "=="
>>>> so when called the macro will be c.s.field == (value).
>>>> if your patch is applied then it will become c.s.field ==(value) .. will that be correct ?
>>>>
>>>> thanks
>>>> sudip
>>>>
>>>>>                             result = 0;                                 \
>>>>>                             break;                                      \
>>>>>                     } else if (cvmx_get_cycle() > done) {               \
>>>>> --
>>>>> 1.9.1
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Kernelnewbies mailing list
>>>>> Kernelnewbies at kernelnewbies.org
>>>>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>>>
>>>> _______________________________________________
>>>> Kernelnewbies mailing list
>>>> Kernelnewbies at kernelnewbies.org
>>>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>>
>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies



-- 
Peter

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [PATCH] staging: Fix spacing between function name and parentheses
  2014-10-11  8:27         ` Peter Senna Tschudin
@ 2014-10-11  9:45           ` Sudip Mukherjee
  2014-10-11  9:53             ` Kristofer Hallin
  0 siblings, 1 reply; 26+ messages in thread
From: Sudip Mukherjee @ 2014-10-11  9:45 UTC (permalink / raw)
  To: kernelnewbies

I agree. But in my opinion checkpatch is here to help us fix style
problems , but we should not blindly act on checkpatch warnings.

thanks
sudip

On Sat, Oct 11, 2014 at 1:57 PM, Peter Senna Tschudin
<peter.senna@gmail.com> wrote:
> I think that, in this case, checkpatch.pl contributed:
>
> $ ./scripts/checkpatch.pl -f drivers/staging/octeon-usb/octeon-hcd.c
> WARNING: space prohibited between function name and open parenthesis '('
> #415: FILE: drivers/staging/octeon-usb/octeon-hcd.c:415:
> +                       if (c.s.field op (value)) {                         \
>
>
> On Sat, Oct 11, 2014 at 8:11 AM, Dave Tian <dave.jing.tian@gmail.com> wrote:
>> Agreed - that is why I mentioned the patch is neither right nor useful:)
>>
>> -daveti
>>
>>
>> On Oct 11, 2014, at 2:08 PM, Sudip Mukherjee <sudipm.mukherjee@gmail.com> wrote:
>>
>>> Hi Dave,
>>> It will work. But my point of saying that was  c.s.field ==(value) is
>>> again not according to the style.
>>>
>>> thanks
>>> sudip
>>>
>>> On Sat, Oct 11, 2014 at 10:53 AM, Dave Tian <dave.jing.tian@gmail.com> wrote:
>>>> It also works as value is surrounded by (), though I do not think the patch itself is right or useful.
>>>>
>>>> Dave Tian
>>>> dave.jing.tian at gmail.com
>>>>
>>>>
>>>>
>>>> On Oct 11, 2014, at 12:58 PM, Sudip Mukherjee <sudipm.mukherjee@gmail.com> wrote:
>>>>
>>>>> On Fri, Oct 10, 2014 at 09:55:48PM -0400, Nicholas Krause wrote:
>>>>>> Fixes checkpatch coding style warning about unneeded space
>>>>>> between function name an parentheses.
>>>>>>
>>>>>> Signed-off-by: Nicholas Krause <xerofoify@gmail.com>
>>>>>> ---
>>>>>> Untested
>>>>>> drivers/staging/octeon-usb/octeon-hcd.c | 2 +-
>>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/drivers/staging/octeon-usb/octeon-hcd.c b/drivers/staging/octeon-usb/octeon-hcd.c
>>>>>> index 5f9db4c..bbeb0cc 100644
>>>>>> --- a/drivers/staging/octeon-usb/octeon-hcd.c
>>>>>> +++ b/drivers/staging/octeon-usb/octeon-hcd.c
>>>>>> @@ -412,7 +412,7 @@ struct octeon_hcd {
>>>>>>             type c;                                                     \
>>>>>>             while (1) {                                                 \
>>>>>>                     c.u32 = __cvmx_usb_read_csr32(usb, address);        \
>>>>>> -                    if (c.s.field op (value)) {                         \
>>>>>> +                    if (c.s.field op(value)) {                          \
>>>>>
>>>>> have you read the code before modifying it?
>>>>> this is not a function.
>>>>> have you seen how CVMX_WAIT_FOR_FIELD32 is being called?
>>>>> on every call of CVMX_WAIT_FOR_FIELD32 op is the operator "=="
>>>>> so when called the macro will be c.s.field == (value).
>>>>> if your patch is applied then it will become c.s.field ==(value) .. will that be correct ?
>>>>>
>>>>> thanks
>>>>> sudip
>>>>>
>>>>>>                             result = 0;                                 \
>>>>>>                             break;                                      \
>>>>>>                     } else if (cvmx_get_cycle() > done) {               \
>>>>>> --
>>>>>> 1.9.1
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Kernelnewbies mailing list
>>>>>> Kernelnewbies at kernelnewbies.org
>>>>>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>>>>
>>>>> _______________________________________________
>>>>> Kernelnewbies mailing list
>>>>> Kernelnewbies at kernelnewbies.org
>>>>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>>>
>>
>>
>> _______________________________________________
>> Kernelnewbies mailing list
>> Kernelnewbies at kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>
>
> --
> Peter

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [PATCH] staging: Fix spacing between function name and parentheses
  2014-10-11  9:45           ` Sudip Mukherjee
@ 2014-10-11  9:53             ` Kristofer Hallin
  2014-10-11 13:44               ` nick
  0 siblings, 1 reply; 26+ messages in thread
From: Kristofer Hallin @ 2014-10-11  9:53 UTC (permalink / raw)
  To: kernelnewbies

Even if you use checkpath you _should_ understand what you are changing.
The output of checkpatch merely there to help.

In this case you can see that this is a macro just a few lines up in the
code.
On 11 Oct 2014 11:46, "Sudip Mukherjee" <sudipm.mukherjee@gmail.com> wrote:

> I agree. But in my opinion checkpatch is here to help us fix style
> problems , but we should not blindly act on checkpatch warnings.
>
> thanks
> sudip
>
> On Sat, Oct 11, 2014 at 1:57 PM, Peter Senna Tschudin
> <peter.senna@gmail.com> wrote:
> > I think that, in this case, checkpatch.pl contributed:
> >
> > $ ./scripts/checkpatch.pl -f drivers/staging/octeon-usb/octeon-hcd.c
> > WARNING: space prohibited between function name and open parenthesis '('
> > #415: FILE: drivers/staging/octeon-usb/octeon-hcd.c:415:
> > +                       if (c.s.field op (value)) {
>    \
> >
> >
> > On Sat, Oct 11, 2014 at 8:11 AM, Dave Tian <dave.jing.tian@gmail.com>
> wrote:
> >> Agreed - that is why I mentioned the patch is neither right nor useful:)
> >>
> >> -daveti
> >>
> >>
> >> On Oct 11, 2014, at 2:08 PM, Sudip Mukherjee <
> sudipm.mukherjee at gmail.com> wrote:
> >>
> >>> Hi Dave,
> >>> It will work. But my point of saying that was  c.s.field ==(value) is
> >>> again not according to the style.
> >>>
> >>> thanks
> >>> sudip
> >>>
> >>> On Sat, Oct 11, 2014 at 10:53 AM, Dave Tian <dave.jing.tian@gmail.com>
> wrote:
> >>>> It also works as value is surrounded by (), though I do not think the
> patch itself is right or useful.
> >>>>
> >>>> Dave Tian
> >>>> dave.jing.tian at gmail.com
> >>>>
> >>>>
> >>>>
> >>>> On Oct 11, 2014, at 12:58 PM, Sudip Mukherjee <
> sudipm.mukherjee at gmail.com> wrote:
> >>>>
> >>>>> On Fri, Oct 10, 2014 at 09:55:48PM -0400, Nicholas Krause wrote:
> >>>>>> Fixes checkpatch coding style warning about unneeded space
> >>>>>> between function name an parentheses.
> >>>>>>
> >>>>>> Signed-off-by: Nicholas Krause <xerofoify@gmail.com>
> >>>>>> ---
> >>>>>> Untested
> >>>>>> drivers/staging/octeon-usb/octeon-hcd.c | 2 +-
> >>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>>>
> >>>>>> diff --git a/drivers/staging/octeon-usb/octeon-hcd.c
> b/drivers/staging/octeon-usb/octeon-hcd.c
> >>>>>> index 5f9db4c..bbeb0cc 100644
> >>>>>> --- a/drivers/staging/octeon-usb/octeon-hcd.c
> >>>>>> +++ b/drivers/staging/octeon-usb/octeon-hcd.c
> >>>>>> @@ -412,7 +412,7 @@ struct octeon_hcd {
> >>>>>>             type c;
>      \
> >>>>>>             while (1) {
>      \
> >>>>>>                     c.u32 = __cvmx_usb_read_csr32(usb, address);
>     \
> >>>>>> -                    if (c.s.field op (value)) {
>      \
> >>>>>> +                    if (c.s.field op(value)) {
>       \
> >>>>>
> >>>>> have you read the code before modifying it?
> >>>>> this is not a function.
> >>>>> have you seen how CVMX_WAIT_FOR_FIELD32 is being called?
> >>>>> on every call of CVMX_WAIT_FOR_FIELD32 op is the operator "=="
> >>>>> so when called the macro will be c.s.field == (value).
> >>>>> if your patch is applied then it will become c.s.field ==(value) ..
> will that be correct ?
> >>>>>
> >>>>> thanks
> >>>>> sudip
> >>>>>
> >>>>>>                             result = 0;
>      \
> >>>>>>                             break;
>     \
> >>>>>>                     } else if (cvmx_get_cycle() > done) {
>      \
> >>>>>> --
> >>>>>> 1.9.1
> >>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> Kernelnewbies mailing list
> >>>>>> Kernelnewbies at kernelnewbies.org
> >>>>>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> >>>>>
> >>>>> _______________________________________________
> >>>>> Kernelnewbies mailing list
> >>>>> Kernelnewbies at kernelnewbies.org
> >>>>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> >>>>
> >>
> >>
> >> _______________________________________________
> >> Kernelnewbies mailing list
> >> Kernelnewbies at kernelnewbies.org
> >> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> >
> >
> >
> > --
> > Peter
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20141011/0dccbd94/attachment.html 

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [PATCH] staging: Fix spacing between function name and parentheses
  2014-10-11  9:53             ` Kristofer Hallin
@ 2014-10-11 13:44               ` nick
  2014-10-11 13:46                 ` Kristofer Hallin
                                   ` (2 more replies)
  0 siblings, 3 replies; 26+ messages in thread
From: nick @ 2014-10-11 13:44 UTC (permalink / raw)
  To: kernelnewbies

Thank you for your help, I'll study the code and see what I can do
about it. Do you have any suggestions of how to fix this checkpatch
warning?
Nick

On 14-10-11 05:53 AM, Kristofer Hallin wrote:
> Even if you use checkpath you _should_ understand what you are changing.
> The output of checkpatch merely there to help.
> 
> In this case you can see that this is a macro just a few lines up in the
> code.
> On 11 Oct 2014 11:46, "Sudip Mukherjee" <sudipm.mukherjee@gmail.com> wrote:
> 
>> I agree. But in my opinion checkpatch is here to help us fix style
>> problems , but we should not blindly act on checkpatch warnings.
>>
>> thanks
>> sudip
>>
>> On Sat, Oct 11, 2014 at 1:57 PM, Peter Senna Tschudin
>> <peter.senna@gmail.com> wrote:
>>> I think that, in this case, checkpatch.pl contributed:
>>>
>>> $ ./scripts/checkpatch.pl -f drivers/staging/octeon-usb/octeon-hcd.c
>>> WARNING: space prohibited between function name and open parenthesis '('
>>> #415: FILE: drivers/staging/octeon-usb/octeon-hcd.c:415:
>>> +                       if (c.s.field op (value)) {
>>    \
>>>
>>>
>>> On Sat, Oct 11, 2014 at 8:11 AM, Dave Tian <dave.jing.tian@gmail.com>
>> wrote:
>>>> Agreed - that is why I mentioned the patch is neither right nor useful:)
>>>>
>>>> -daveti
>>>>
>>>>
>>>> On Oct 11, 2014, at 2:08 PM, Sudip Mukherjee <
>> sudipm.mukherjee at gmail.com> wrote:
>>>>
>>>>> Hi Dave,
>>>>> It will work. But my point of saying that was  c.s.field ==(value) is
>>>>> again not according to the style.
>>>>>
>>>>> thanks
>>>>> sudip
>>>>>
>>>>> On Sat, Oct 11, 2014 at 10:53 AM, Dave Tian <dave.jing.tian@gmail.com>
>> wrote:
>>>>>> It also works as value is surrounded by (), though I do not think the
>> patch itself is right or useful.
>>>>>>
>>>>>> Dave Tian
>>>>>> dave.jing.tian at gmail.com
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Oct 11, 2014, at 12:58 PM, Sudip Mukherjee <
>> sudipm.mukherjee at gmail.com> wrote:
>>>>>>
>>>>>>> On Fri, Oct 10, 2014 at 09:55:48PM -0400, Nicholas Krause wrote:
>>>>>>>> Fixes checkpatch coding style warning about unneeded space
>>>>>>>> between function name an parentheses.
>>>>>>>>
>>>>>>>> Signed-off-by: Nicholas Krause <xerofoify@gmail.com>
>>>>>>>> ---
>>>>>>>> Untested
>>>>>>>> drivers/staging/octeon-usb/octeon-hcd.c | 2 +-
>>>>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>>>
>>>>>>>> diff --git a/drivers/staging/octeon-usb/octeon-hcd.c
>> b/drivers/staging/octeon-usb/octeon-hcd.c
>>>>>>>> index 5f9db4c..bbeb0cc 100644
>>>>>>>> --- a/drivers/staging/octeon-usb/octeon-hcd.c
>>>>>>>> +++ b/drivers/staging/octeon-usb/octeon-hcd.c
>>>>>>>> @@ -412,7 +412,7 @@ struct octeon_hcd {
>>>>>>>>             type c;
>>      \
>>>>>>>>             while (1) {
>>      \
>>>>>>>>                     c.u32 = __cvmx_usb_read_csr32(usb, address);
>>     \
>>>>>>>> -                    if (c.s.field op (value)) {
>>      \
>>>>>>>> +                    if (c.s.field op(value)) {
>>       \
>>>>>>>
>>>>>>> have you read the code before modifying it?
>>>>>>> this is not a function.
>>>>>>> have you seen how CVMX_WAIT_FOR_FIELD32 is being called?
>>>>>>> on every call of CVMX_WAIT_FOR_FIELD32 op is the operator "=="
>>>>>>> so when called the macro will be c.s.field == (value).
>>>>>>> if your patch is applied then it will become c.s.field ==(value) ..
>> will that be correct ?
>>>>>>>
>>>>>>> thanks
>>>>>>> sudip
>>>>>>>
>>>>>>>>                             result = 0;
>>      \
>>>>>>>>                             break;
>>     \
>>>>>>>>                     } else if (cvmx_get_cycle() > done) {
>>      \
>>>>>>>> --
>>>>>>>> 1.9.1
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Kernelnewbies mailing list
>>>>>>>> Kernelnewbies at kernelnewbies.org
>>>>>>>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Kernelnewbies mailing list
>>>>>>> Kernelnewbies at kernelnewbies.org
>>>>>>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Kernelnewbies mailing list
>>>> Kernelnewbies at kernelnewbies.org
>>>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>>
>>>
>>>
>>> --
>>> Peter
>>
>> _______________________________________________
>> Kernelnewbies mailing list
>> Kernelnewbies at kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>
> 

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [PATCH] staging: Fix spacing between function name and parentheses
  2014-10-11 13:44               ` nick
@ 2014-10-11 13:46                 ` Kristofer Hallin
  2014-10-11 13:52                 ` Hugo Mills
  2014-10-11 14:24                 ` Robert P. J. Day
  2 siblings, 0 replies; 26+ messages in thread
From: Kristofer Hallin @ 2014-10-11 13:46 UTC (permalink / raw)
  To: kernelnewbies

Don't. Haven't you learnt anything from your previous attempts?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20141011/e90ef16e/attachment.html 

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [PATCH] staging: Fix spacing between function name and parentheses
  2014-10-11 13:44               ` nick
  2014-10-11 13:46                 ` Kristofer Hallin
@ 2014-10-11 13:52                 ` Hugo Mills
  2014-10-11 14:17                   ` nick
  2014-10-12 22:34                   ` Valdis.Kletnieks at vt.edu
  2014-10-11 14:24                 ` Robert P. J. Day
  2 siblings, 2 replies; 26+ messages in thread
From: Hugo Mills @ 2014-10-11 13:52 UTC (permalink / raw)
  To: kernelnewbies

On Sat, Oct 11, 2014 at 09:44:05AM -0400, nick wrote:
> Thank you for your help, I'll study the code and see what I can do
> about it. Do you have any suggestions of how to fix this checkpatch
> warning?

   Ignore it. The checker has clearly triggered on a false positive --
this is not a function call, and should not be held to that standard.
(Take a look at where the macro is actually used, to see what's going
on here). Move on to find something more interesting to fix.

   Hugo.

> Nick
> 
> On 14-10-11 05:53 AM, Kristofer Hallin wrote:
> > Even if you use checkpath you _should_ understand what you are changing.
> > The output of checkpatch merely there to help.
> > 
> > In this case you can see that this is a macro just a few lines up in the
> > code.
> > On 11 Oct 2014 11:46, "Sudip Mukherjee" <sudipm.mukherjee@gmail.com> wrote:
> > 
> >> I agree. But in my opinion checkpatch is here to help us fix style
> >> problems , but we should not blindly act on checkpatch warnings.
> >>
> >> thanks
> >> sudip
> >>
> >> On Sat, Oct 11, 2014 at 1:57 PM, Peter Senna Tschudin
> >> <peter.senna@gmail.com> wrote:
> >>> I think that, in this case, checkpatch.pl contributed:
> >>>
> >>> $ ./scripts/checkpatch.pl -f drivers/staging/octeon-usb/octeon-hcd.c
> >>> WARNING: space prohibited between function name and open parenthesis '('
> >>> #415: FILE: drivers/staging/octeon-usb/octeon-hcd.c:415:
> >>> +                       if (c.s.field op (value)) {
> >>    \
> >>>
> >>>
> >>> On Sat, Oct 11, 2014 at 8:11 AM, Dave Tian <dave.jing.tian@gmail.com>
> >> wrote:
> >>>> Agreed - that is why I mentioned the patch is neither right nor useful:)
> >>>>
> >>>> -daveti
> >>>>
> >>>>
> >>>> On Oct 11, 2014, at 2:08 PM, Sudip Mukherjee <
> >> sudipm.mukherjee at gmail.com> wrote:
> >>>>
> >>>>> Hi Dave,
> >>>>> It will work. But my point of saying that was  c.s.field ==(value) is
> >>>>> again not according to the style.
> >>>>>
> >>>>> thanks
> >>>>> sudip
> >>>>>
> >>>>> On Sat, Oct 11, 2014 at 10:53 AM, Dave Tian <dave.jing.tian@gmail.com>
> >> wrote:
> >>>>>> It also works as value is surrounded by (), though I do not think the
> >> patch itself is right or useful.
> >>>>>>
> >>>>>> Dave Tian
> >>>>>> dave.jing.tian at gmail.com
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Oct 11, 2014, at 12:58 PM, Sudip Mukherjee <
> >> sudipm.mukherjee at gmail.com> wrote:
> >>>>>>
> >>>>>>> On Fri, Oct 10, 2014 at 09:55:48PM -0400, Nicholas Krause wrote:
> >>>>>>>> Fixes checkpatch coding style warning about unneeded space
> >>>>>>>> between function name an parentheses.
> >>>>>>>>
> >>>>>>>> Signed-off-by: Nicholas Krause <xerofoify@gmail.com>
> >>>>>>>> ---
> >>>>>>>> Untested
> >>>>>>>> drivers/staging/octeon-usb/octeon-hcd.c | 2 +-
> >>>>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>>>>>
> >>>>>>>> diff --git a/drivers/staging/octeon-usb/octeon-hcd.c
> >> b/drivers/staging/octeon-usb/octeon-hcd.c
> >>>>>>>> index 5f9db4c..bbeb0cc 100644
> >>>>>>>> --- a/drivers/staging/octeon-usb/octeon-hcd.c
> >>>>>>>> +++ b/drivers/staging/octeon-usb/octeon-hcd.c
> >>>>>>>> @@ -412,7 +412,7 @@ struct octeon_hcd {
> >>>>>>>>             type c;
> >>      \
> >>>>>>>>             while (1) {
> >>      \
> >>>>>>>>                     c.u32 = __cvmx_usb_read_csr32(usb, address);
> >>     \
> >>>>>>>> -                    if (c.s.field op (value)) {
> >>      \
> >>>>>>>> +                    if (c.s.field op(value)) {
> >>       \
> >>>>>>>
> >>>>>>> have you read the code before modifying it?
> >>>>>>> this is not a function.
> >>>>>>> have you seen how CVMX_WAIT_FOR_FIELD32 is being called?
> >>>>>>> on every call of CVMX_WAIT_FOR_FIELD32 op is the operator "=="
> >>>>>>> so when called the macro will be c.s.field == (value).
> >>>>>>> if your patch is applied then it will become c.s.field ==(value) ..
> >> will that be correct ?
> >>>>>>>
> >>>>>>> thanks
> >>>>>>> sudip
> >>>>>>>
> >>>>>>>>                             result = 0;
> >>      \
> >>>>>>>>                             break;
> >>     \
> >>>>>>>>                     } else if (cvmx_get_cycle() > done) {
> >>      \

-- 
=== 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
             --- Happiness is mandatory.  Are you happy? ---             
-------------- 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/20141011/a7281663/attachment-0001.bin 

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [PATCH] staging: Fix spacing between function name and parentheses
  2014-10-11 13:52                 ` Hugo Mills
@ 2014-10-11 14:17                   ` nick
  2014-10-11 15:25                     ` karthik nayak
  2014-10-12 22:34                   ` Valdis.Kletnieks at vt.edu
  1 sibling, 1 reply; 26+ messages in thread
From: nick @ 2014-10-11 14:17 UTC (permalink / raw)
  To: kernelnewbies

Thanks Hugo,
Sorry about that. On the other hand was the patch good in terms of format?
Cheers Nick 

On 14-10-11 09:52 AM, Hugo Mills wrote:
> On Sat, Oct 11, 2014 at 09:44:05AM -0400, nick wrote:
>> Thank you for your help, I'll study the code and see what I can do
>> about it. Do you have any suggestions of how to fix this checkpatch
>> warning?
> 
>    Ignore it. The checker has clearly triggered on a false positive --
> this is not a function call, and should not be held to that standard.
> (Take a look at where the macro is actually used, to see what's going
> on here). Move on to find something more interesting to fix.
> 
>    Hugo.
> 
>> Nick
>>
>> On 14-10-11 05:53 AM, Kristofer Hallin wrote:
>>> Even if you use checkpath you _should_ understand what you are changing.
>>> The output of checkpatch merely there to help.
>>>
>>> In this case you can see that this is a macro just a few lines up in the
>>> code.
>>> On 11 Oct 2014 11:46, "Sudip Mukherjee" <sudipm.mukherjee@gmail.com> wrote:
>>>
>>>> I agree. But in my opinion checkpatch is here to help us fix style
>>>> problems , but we should not blindly act on checkpatch warnings.
>>>>
>>>> thanks
>>>> sudip
>>>>
>>>> On Sat, Oct 11, 2014 at 1:57 PM, Peter Senna Tschudin
>>>> <peter.senna@gmail.com> wrote:
>>>>> I think that, in this case, checkpatch.pl contributed:
>>>>>
>>>>> $ ./scripts/checkpatch.pl -f drivers/staging/octeon-usb/octeon-hcd.c
>>>>> WARNING: space prohibited between function name and open parenthesis '('
>>>>> #415: FILE: drivers/staging/octeon-usb/octeon-hcd.c:415:
>>>>> +                       if (c.s.field op (value)) {
>>>>    \
>>>>>
>>>>>
>>>>> On Sat, Oct 11, 2014 at 8:11 AM, Dave Tian <dave.jing.tian@gmail.com>
>>>> wrote:
>>>>>> Agreed - that is why I mentioned the patch is neither right nor useful:)
>>>>>>
>>>>>> -daveti
>>>>>>
>>>>>>
>>>>>> On Oct 11, 2014, at 2:08 PM, Sudip Mukherjee <
>>>> sudipm.mukherjee at gmail.com> wrote:
>>>>>>
>>>>>>> Hi Dave,
>>>>>>> It will work. But my point of saying that was  c.s.field ==(value) is
>>>>>>> again not according to the style.
>>>>>>>
>>>>>>> thanks
>>>>>>> sudip
>>>>>>>
>>>>>>> On Sat, Oct 11, 2014 at 10:53 AM, Dave Tian <dave.jing.tian@gmail.com>
>>>> wrote:
>>>>>>>> It also works as value is surrounded by (), though I do not think the
>>>> patch itself is right or useful.
>>>>>>>>
>>>>>>>> Dave Tian
>>>>>>>> dave.jing.tian at gmail.com
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Oct 11, 2014, at 12:58 PM, Sudip Mukherjee <
>>>> sudipm.mukherjee at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> On Fri, Oct 10, 2014 at 09:55:48PM -0400, Nicholas Krause wrote:
>>>>>>>>>> Fixes checkpatch coding style warning about unneeded space
>>>>>>>>>> between function name an parentheses.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Nicholas Krause <xerofoify@gmail.com>
>>>>>>>>>> ---
>>>>>>>>>> Untested
>>>>>>>>>> drivers/staging/octeon-usb/octeon-hcd.c | 2 +-
>>>>>>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>>>>>
>>>>>>>>>> diff --git a/drivers/staging/octeon-usb/octeon-hcd.c
>>>> b/drivers/staging/octeon-usb/octeon-hcd.c
>>>>>>>>>> index 5f9db4c..bbeb0cc 100644
>>>>>>>>>> --- a/drivers/staging/octeon-usb/octeon-hcd.c
>>>>>>>>>> +++ b/drivers/staging/octeon-usb/octeon-hcd.c
>>>>>>>>>> @@ -412,7 +412,7 @@ struct octeon_hcd {
>>>>>>>>>>             type c;
>>>>      \
>>>>>>>>>>             while (1) {
>>>>      \
>>>>>>>>>>                     c.u32 = __cvmx_usb_read_csr32(usb, address);
>>>>     \
>>>>>>>>>> -                    if (c.s.field op (value)) {
>>>>      \
>>>>>>>>>> +                    if (c.s.field op(value)) {
>>>>       \
>>>>>>>>>
>>>>>>>>> have you read the code before modifying it?
>>>>>>>>> this is not a function.
>>>>>>>>> have you seen how CVMX_WAIT_FOR_FIELD32 is being called?
>>>>>>>>> on every call of CVMX_WAIT_FOR_FIELD32 op is the operator "=="
>>>>>>>>> so when called the macro will be c.s.field == (value).
>>>>>>>>> if your patch is applied then it will become c.s.field ==(value) ..
>>>> will that be correct ?
>>>>>>>>>
>>>>>>>>> thanks
>>>>>>>>> sudip
>>>>>>>>>
>>>>>>>>>>                             result = 0;
>>>>      \
>>>>>>>>>>                             break;
>>>>     \
>>>>>>>>>>                     } else if (cvmx_get_cycle() > done) {
>>>>      \
> 

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [PATCH] staging: Fix spacing between function name and parentheses
  2014-10-11 13:44               ` nick
  2014-10-11 13:46                 ` Kristofer Hallin
  2014-10-11 13:52                 ` Hugo Mills
@ 2014-10-11 14:24                 ` Robert P. J. Day
  2 siblings, 0 replies; 26+ messages in thread
From: Robert P. J. Day @ 2014-10-11 14:24 UTC (permalink / raw)
  To: kernelnewbies

On Sat, 11 Oct 2014, nick wrote:

> Thank you for your help, I'll study the code and see what I can do
> about it. Do you have any suggestions of how to fix this checkpatch
> warning?

  there is absolutely nothing wrong with that code -- the problem is
your utter lack of understanding.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [PATCH] staging: Fix spacing between function name and parentheses
  2014-10-11 14:17                   ` nick
@ 2014-10-11 15:25                     ` karthik nayak
  2014-10-11 22:18                       ` nick
  0 siblings, 1 reply; 26+ messages in thread
From: karthik nayak @ 2014-10-11 15:25 UTC (permalink / raw)
  To: kernelnewbies

Hey Nick,
Nice try to fix a checkpatch warning. But do read what you're changing.
Yes your format is right. If you haven't already, take a look at "git
send-email" .
Have fun hacking :D
Regards,
Karthik Nayak


On Sat, Oct 11, 2014 at 7:47 PM, nick <xerofoify@gmail.com> wrote:
> Thanks Hugo,
> Sorry about that. On the other hand was the patch good in terms of format?
> Cheers Nick
>
> On 14-10-11 09:52 AM, Hugo Mills wrote:
>> On Sat, Oct 11, 2014 at 09:44:05AM -0400, nick wrote:
>>> Thank you for your help, I'll study the code and see what I can do
>>> about it. Do you have any suggestions of how to fix this checkpatch
>>> warning?
>>
>>    Ignore it. The checker has clearly triggered on a false positive --
>> this is not a function call, and should not be held to that standard.
>> (Take a look at where the macro is actually used, to see what's going
>> on here). Move on to find something more interesting to fix.
>>
>>    Hugo.
>>
>>> Nick
>>>
>>> On 14-10-11 05:53 AM, Kristofer Hallin wrote:
>>>> Even if you use checkpath you _should_ understand what you are changing.
>>>> The output of checkpatch merely there to help.
>>>>
>>>> In this case you can see that this is a macro just a few lines up in the
>>>> code.
>>>> On 11 Oct 2014 11:46, "Sudip Mukherjee" <sudipm.mukherjee@gmail.com> wrote:
>>>>
>>>>> I agree. But in my opinion checkpatch is here to help us fix style
>>>>> problems , but we should not blindly act on checkpatch warnings.
>>>>>
>>>>> thanks
>>>>> sudip
>>>>>
>>>>> On Sat, Oct 11, 2014 at 1:57 PM, Peter Senna Tschudin
>>>>> <peter.senna@gmail.com> wrote:
>>>>>> I think that, in this case, checkpatch.pl contributed:
>>>>>>
>>>>>> $ ./scripts/checkpatch.pl -f drivers/staging/octeon-usb/octeon-hcd.c
>>>>>> WARNING: space prohibited between function name and open parenthesis '('
>>>>>> #415: FILE: drivers/staging/octeon-usb/octeon-hcd.c:415:
>>>>>> +                       if (c.s.field op (value)) {
>>>>>    \
>>>>>>
>>>>>>
>>>>>> On Sat, Oct 11, 2014 at 8:11 AM, Dave Tian <dave.jing.tian@gmail.com>
>>>>> wrote:
>>>>>>> Agreed - that is why I mentioned the patch is neither right nor useful:)
>>>>>>>
>>>>>>> -daveti
>>>>>>>
>>>>>>>
>>>>>>> On Oct 11, 2014, at 2:08 PM, Sudip Mukherjee <
>>>>> sudipm.mukherjee at gmail.com> wrote:
>>>>>>>
>>>>>>>> Hi Dave,
>>>>>>>> It will work. But my point of saying that was  c.s.field ==(value) is
>>>>>>>> again not according to the style.
>>>>>>>>
>>>>>>>> thanks
>>>>>>>> sudip
>>>>>>>>
>>>>>>>> On Sat, Oct 11, 2014 at 10:53 AM, Dave Tian <dave.jing.tian@gmail.com>
>>>>> wrote:
>>>>>>>>> It also works as value is surrounded by (), though I do not think the
>>>>> patch itself is right or useful.
>>>>>>>>>
>>>>>>>>> Dave Tian
>>>>>>>>> dave.jing.tian at gmail.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Oct 11, 2014, at 12:58 PM, Sudip Mukherjee <
>>>>> sudipm.mukherjee at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> On Fri, Oct 10, 2014 at 09:55:48PM -0400, Nicholas Krause wrote:
>>>>>>>>>>> Fixes checkpatch coding style warning about unneeded space
>>>>>>>>>>> between function name an parentheses.
>>>>>>>>>>>
>>>>>>>>>>> Signed-off-by: Nicholas Krause <xerofoify@gmail.com>
>>>>>>>>>>> ---
>>>>>>>>>>> Untested
>>>>>>>>>>> drivers/staging/octeon-usb/octeon-hcd.c | 2 +-
>>>>>>>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>>>>>>
>>>>>>>>>>> diff --git a/drivers/staging/octeon-usb/octeon-hcd.c
>>>>> b/drivers/staging/octeon-usb/octeon-hcd.c
>>>>>>>>>>> index 5f9db4c..bbeb0cc 100644
>>>>>>>>>>> --- a/drivers/staging/octeon-usb/octeon-hcd.c
>>>>>>>>>>> +++ b/drivers/staging/octeon-usb/octeon-hcd.c
>>>>>>>>>>> @@ -412,7 +412,7 @@ struct octeon_hcd {
>>>>>>>>>>>             type c;
>>>>>      \
>>>>>>>>>>>             while (1) {
>>>>>      \
>>>>>>>>>>>                     c.u32 = __cvmx_usb_read_csr32(usb, address);
>>>>>     \
>>>>>>>>>>> -                    if (c.s.field op (value)) {
>>>>>      \
>>>>>>>>>>> +                    if (c.s.field op(value)) {
>>>>>       \
>>>>>>>>>>
>>>>>>>>>> have you read the code before modifying it?
>>>>>>>>>> this is not a function.
>>>>>>>>>> have you seen how CVMX_WAIT_FOR_FIELD32 is being called?
>>>>>>>>>> on every call of CVMX_WAIT_FOR_FIELD32 op is the operator "=="
>>>>>>>>>> so when called the macro will be c.s.field == (value).
>>>>>>>>>> if your patch is applied then it will become c.s.field ==(value) ..
>>>>> will that be correct ?
>>>>>>>>>>
>>>>>>>>>> thanks
>>>>>>>>>> sudip
>>>>>>>>>>
>>>>>>>>>>>                             result = 0;
>>>>>      \
>>>>>>>>>>>                             break;
>>>>>     \
>>>>>>>>>>>                     } else if (cvmx_get_cycle() > done) {
>>>>>      \
>>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [PATCH] staging: Fix spacing between function name and parentheses
  2014-10-11 15:25                     ` karthik nayak
@ 2014-10-11 22:18                       ` nick
  0 siblings, 0 replies; 26+ messages in thread
From: nick @ 2014-10-11 22:18 UTC (permalink / raw)
  To: kernelnewbies

Great to known. Sorry about not reading the code, will check more carefully
before I fix it.
Regards Nick 

On 14-10-11 11:25 AM, karthik nayak wrote:
> Hey Nick,
> Nice try to fix a checkpatch warning. But do read what you're changing.
> Yes your format is right. If you haven't already, take a look at "git
> send-email" .
> Have fun hacking :D
> Regards,
> Karthik Nayak
> 
> 
> On Sat, Oct 11, 2014 at 7:47 PM, nick <xerofoify@gmail.com> wrote:
>> Thanks Hugo,
>> Sorry about that. On the other hand was the patch good in terms of format?
>> Cheers Nick
>>
>> On 14-10-11 09:52 AM, Hugo Mills wrote:
>>> On Sat, Oct 11, 2014 at 09:44:05AM -0400, nick wrote:
>>>> Thank you for your help, I'll study the code and see what I can do
>>>> about it. Do you have any suggestions of how to fix this checkpatch
>>>> warning?
>>>
>>>    Ignore it. The checker has clearly triggered on a false positive --
>>> this is not a function call, and should not be held to that standard.
>>> (Take a look at where the macro is actually used, to see what's going
>>> on here). Move on to find something more interesting to fix.
>>>
>>>    Hugo.
>>>
>>>> Nick
>>>>
>>>> On 14-10-11 05:53 AM, Kristofer Hallin wrote:
>>>>> Even if you use checkpath you _should_ understand what you are changing.
>>>>> The output of checkpatch merely there to help.
>>>>>
>>>>> In this case you can see that this is a macro just a few lines up in the
>>>>> code.
>>>>> On 11 Oct 2014 11:46, "Sudip Mukherjee" <sudipm.mukherjee@gmail.com> wrote:
>>>>>
>>>>>> I agree. But in my opinion checkpatch is here to help us fix style
>>>>>> problems , but we should not blindly act on checkpatch warnings.
>>>>>>
>>>>>> thanks
>>>>>> sudip
>>>>>>
>>>>>> On Sat, Oct 11, 2014 at 1:57 PM, Peter Senna Tschudin
>>>>>> <peter.senna@gmail.com> wrote:
>>>>>>> I think that, in this case, checkpatch.pl contributed:
>>>>>>>
>>>>>>> $ ./scripts/checkpatch.pl -f drivers/staging/octeon-usb/octeon-hcd.c
>>>>>>> WARNING: space prohibited between function name and open parenthesis '('
>>>>>>> #415: FILE: drivers/staging/octeon-usb/octeon-hcd.c:415:
>>>>>>> +                       if (c.s.field op (value)) {
>>>>>>    \
>>>>>>>
>>>>>>>
>>>>>>> On Sat, Oct 11, 2014 at 8:11 AM, Dave Tian <dave.jing.tian@gmail.com>
>>>>>> wrote:
>>>>>>>> Agreed - that is why I mentioned the patch is neither right nor useful:)
>>>>>>>>
>>>>>>>> -daveti
>>>>>>>>
>>>>>>>>
>>>>>>>> On Oct 11, 2014, at 2:08 PM, Sudip Mukherjee <
>>>>>> sudipm.mukherjee at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Hi Dave,
>>>>>>>>> It will work. But my point of saying that was  c.s.field ==(value) is
>>>>>>>>> again not according to the style.
>>>>>>>>>
>>>>>>>>> thanks
>>>>>>>>> sudip
>>>>>>>>>
>>>>>>>>> On Sat, Oct 11, 2014 at 10:53 AM, Dave Tian <dave.jing.tian@gmail.com>
>>>>>> wrote:
>>>>>>>>>> It also works as value is surrounded by (), though I do not think the
>>>>>> patch itself is right or useful.
>>>>>>>>>>
>>>>>>>>>> Dave Tian
>>>>>>>>>> dave.jing.tian at gmail.com
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Oct 11, 2014, at 12:58 PM, Sudip Mukherjee <
>>>>>> sudipm.mukherjee at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> On Fri, Oct 10, 2014 at 09:55:48PM -0400, Nicholas Krause wrote:
>>>>>>>>>>>> Fixes checkpatch coding style warning about unneeded space
>>>>>>>>>>>> between function name an parentheses.
>>>>>>>>>>>>
>>>>>>>>>>>> Signed-off-by: Nicholas Krause <xerofoify@gmail.com>
>>>>>>>>>>>> ---
>>>>>>>>>>>> Untested
>>>>>>>>>>>> drivers/staging/octeon-usb/octeon-hcd.c | 2 +-
>>>>>>>>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>>>>>>>
>>>>>>>>>>>> diff --git a/drivers/staging/octeon-usb/octeon-hcd.c
>>>>>> b/drivers/staging/octeon-usb/octeon-hcd.c
>>>>>>>>>>>> index 5f9db4c..bbeb0cc 100644
>>>>>>>>>>>> --- a/drivers/staging/octeon-usb/octeon-hcd.c
>>>>>>>>>>>> +++ b/drivers/staging/octeon-usb/octeon-hcd.c
>>>>>>>>>>>> @@ -412,7 +412,7 @@ struct octeon_hcd {
>>>>>>>>>>>>             type c;
>>>>>>      \
>>>>>>>>>>>>             while (1) {
>>>>>>      \
>>>>>>>>>>>>                     c.u32 = __cvmx_usb_read_csr32(usb, address);
>>>>>>     \
>>>>>>>>>>>> -                    if (c.s.field op (value)) {
>>>>>>      \
>>>>>>>>>>>> +                    if (c.s.field op(value)) {
>>>>>>       \
>>>>>>>>>>>
>>>>>>>>>>> have you read the code before modifying it?
>>>>>>>>>>> this is not a function.
>>>>>>>>>>> have you seen how CVMX_WAIT_FOR_FIELD32 is being called?
>>>>>>>>>>> on every call of CVMX_WAIT_FOR_FIELD32 op is the operator "=="
>>>>>>>>>>> so when called the macro will be c.s.field == (value).
>>>>>>>>>>> if your patch is applied then it will become c.s.field ==(value) ..
>>>>>> will that be correct ?
>>>>>>>>>>>
>>>>>>>>>>> thanks
>>>>>>>>>>> sudip
>>>>>>>>>>>
>>>>>>>>>>>>                             result = 0;
>>>>>>      \
>>>>>>>>>>>>                             break;
>>>>>>     \
>>>>>>>>>>>>                     } else if (cvmx_get_cycle() > done) {
>>>>>>      \
>>>
>>
>> _______________________________________________
>> Kernelnewbies mailing list
>> Kernelnewbies at kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [PATCH] staging: Fix spacing between function name and parentheses
  2014-10-11 13:52                 ` Hugo Mills
  2014-10-11 14:17                   ` nick
@ 2014-10-12 22:34                   ` Valdis.Kletnieks at vt.edu
  2014-10-13  2:31                     ` nick
  2014-10-13  4:55                     ` Sudip Mukherjee
  1 sibling, 2 replies; 26+ messages in thread
From: Valdis.Kletnieks at vt.edu @ 2014-10-12 22:34 UTC (permalink / raw)
  To: kernelnewbies

On Sat, 11 Oct 2014 14:52:40 +0100, Hugo Mills said:

> On Sat, Oct 11, 2014 at 09:44:05AM -0400, nick wrote:
> > Thank you for your help, I'll study the code and see what I can do
> > about it. Do you have any suggestions of how to fix this checkpatch
> > warning?
>
>    Ignore it. The checker has clearly triggered on a false positive --
> this is not a function call, and should not be held to that standard.
> (Take a look at where the macro is actually used, to see what's going
> on here). Move on to find something more interesting to fix.

Am I the only one suspicious of the fact that Nick found one of the
few false positives rather than one of the plentiful actual style
problems?
-------------- 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/20141012/eb18dacc/attachment.bin 

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [PATCH] staging: Fix spacing between function name and parentheses
  2014-10-12 22:34                   ` Valdis.Kletnieks at vt.edu
@ 2014-10-13  2:31                     ` nick
  2014-10-13  3:15                       ` Valdis.Kletnieks at vt.edu
  2014-10-13  4:55                     ` Sudip Mukherjee
  1 sibling, 1 reply; 26+ messages in thread
From: nick @ 2014-10-13  2:31 UTC (permalink / raw)
  To: kernelnewbies

Valdis,
I do understand your concern with me finding one of the few false positives,
due to my issues already with the community. I am trying my best now to improve
and work toward good,solid work that is of actual use to the community and avoid
shitty patches and not listening like I did for the last few months.
Sorry,
Nick 

On 14-10-12 06:34 PM, Valdis.Kletnieks at vt.edu wrote:
> On Sat, 11 Oct 2014 14:52:40 +0100, Hugo Mills said:
> 
>> On Sat, Oct 11, 2014 at 09:44:05AM -0400, nick wrote:
>>> Thank you for your help, I'll study the code and see what I can do
>>> about it. Do you have any suggestions of how to fix this checkpatch
>>> warning?
>>
>>    Ignore it. The checker has clearly triggered on a false positive --
>> this is not a function call, and should not be held to that standard.
>> (Take a look at where the macro is actually used, to see what's going
>> on here). Move on to find something more interesting to fix.
> 
> Am I the only one suspicious of the fact that Nick found one of the
> few false positives rather than one of the plentiful actual style
> problems?
> 

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [PATCH] staging: Fix spacing between function name and parentheses
  2014-10-13  2:31                     ` nick
@ 2014-10-13  3:15                       ` Valdis.Kletnieks at vt.edu
  0 siblings, 0 replies; 26+ messages in thread
From: Valdis.Kletnieks at vt.edu @ 2014-10-13  3:15 UTC (permalink / raw)
  To: kernelnewbies

On Sun, 12 Oct 2014 22:31:12 -0400, nick said:
> Valdis,
> I do understand your concern with me finding one of the few false positives,
> due to my issues already with the community. I am trying my best now to improve
> and work toward good,solid work that is of actual use to the community and avoid
> shitty patches and not listening like I did for the last few months.

Forget it Nick.  We've heard that too many times.  And this time, you blew it
by making your bad patch a bit *too* unbelievable. We're tired of your
trolling.

Where's my drum of Troll-be-gone?
-------------- 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/20141012/28aeff75/attachment.bin 

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [PATCH] staging: Fix spacing between function name and parentheses
  2014-10-12 22:34                   ` Valdis.Kletnieks at vt.edu
  2014-10-13  2:31                     ` nick
@ 2014-10-13  4:55                     ` Sudip Mukherjee
  2014-10-14 15:38                       ` Adrian Cornish
  1 sibling, 1 reply; 26+ messages in thread
From: Sudip Mukherjee @ 2014-10-13  4:55 UTC (permalink / raw)
  To: kernelnewbies

On Mon, Oct 13, 2014 at 4:04 AM,  <Valdis.Kletnieks@vt.edu> wrote:
> On Sat, 11 Oct 2014 14:52:40 +0100, Hugo Mills said:
>
>> On Sat, Oct 11, 2014 at 09:44:05AM -0400, nick wrote:
>> > Thank you for your help, I'll study the code and see what I can do
>> > about it. Do you have any suggestions of how to fix this checkpatch
>> > warning?
>>
>>    Ignore it. The checker has clearly triggered on a false positive --
>> this is not a function call, and should not be held to that standard.
>> (Take a look at where the macro is actually used, to see what's going
>> on here). Move on to find something more interesting to fix.
>
> Am I the only one suspicious of the fact that Nick found one of the
> few false positives rather than one of the plentiful actual style
> problems?
no , you are not the only one. That particular file has lots of
checkpatch warning , and our Nick choose just the one which is a false
positive.

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [PATCH] staging: Fix spacing between function name and parentheses
  2014-10-13  4:55                     ` Sudip Mukherjee
@ 2014-10-14 15:38                       ` Adrian Cornish
  2014-10-14 18:11                         ` Kernel Apprentice
                                           ` (2 more replies)
  0 siblings, 3 replies; 26+ messages in thread
From: Adrian Cornish @ 2014-10-14 15:38 UTC (permalink / raw)
  To: kernelnewbies



-----Original Message-----
From: kernelnewbies-bounces@kernelnewbies.org [mailto:kernelnewbies-bounces at kernelnewbies.org] On Behalf Of Sudip Mukherjee
Sent: Sunday, October 12, 2014 10:56 PM
To: Valdis Kletnieks
Cc: Dave Tian; nick; Kristofer Hallin; kernelnewbies; Peter Senna Tschudin; Hugo Mills
Subject: Re: [PATCH] staging: Fix spacing between function name and parentheses

On Mon, Oct 13, 2014 at 4:04 AM,  <Valdis.Kletnieks@vt.edu> wrote:
> On Sat, 11 Oct 2014 14:52:40 +0100, Hugo Mills said:
>
>> On Sat, Oct 11, 2014 at 09:44:05AM -0400, nick wrote:
>> > Thank you for your help, I'll study the code and see what I can do
>> > about it. Do you have any suggestions of how to fix this checkpatch
>> > warning?
>>
>>    Ignore it. The checker has clearly triggered on a false positive --
>> this is not a function call, and should not be held to that standard.
>> (Take a look at where the macro is actually used, to see what's going
>> on here). Move on to find something more interesting to fix.
>
> Am I the only one suspicious of the fact that Nick found one of the
> few false positives rather than one of the plentiful actual style
> problems?
no , you are not the only one. That particular file has lots of
checkpatch warning , and our Nick choose just the one which is a false
positive.



What is wrong with you people - were you never on nntp and learned how to ignore trolls? I only read this list and Nicholas Krause is a pain - why where there ~11 responses to his stuff - he should be ignored - he is not banned to never respond to the idiot.

Nobody wants him, he only wants a byline of minor fame by says 'he I wrote some of linux' 3 months of this crap and you are still all entertaining someone with no code skill accept from adding/removing spaces - we all need house cleaners - but I would not trust him to clean my toilet correctly. 

I raise the simple motion that when Nicholas Krause posts - NOBODY responds to him - EVER - under threat of torture or whatever - for whatever reason - my joy of lurking here has been ruined by a single IDIOT - if this was nntp he would have wandered off a long time ago with ignores - but I blame this list for constantly responding to the TROLL and FEEDING it. DONT DO IT

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [PATCH] staging: Fix spacing between function name and parentheses
  2014-10-14 15:38                       ` Adrian Cornish
@ 2014-10-14 18:11                         ` Kernel Apprentice
  2014-10-14 21:08                         ` John de la Garza
  2014-10-20  9:17                         ` el_es
  2 siblings, 0 replies; 26+ messages in thread
From: Kernel Apprentice @ 2014-10-14 18:11 UTC (permalink / raw)
  To: kernelnewbies


> I raise the simple motion that when Nicholas Krause posts - NOBODY responds to him - EVER - under threat of torture or whatever - for whatever reason - my joy of lurking here has been ruined by a single IDIOT - if this was nntp he would have wandered off a long time ago with ignores - but I blame this list for constantly responding to the TROLL and FEEDING it. DONT DO IT

Couldn't agree more. Just don't.

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [PATCH] staging: Fix spacing between function name and parentheses
  2014-10-14 15:38                       ` Adrian Cornish
  2014-10-14 18:11                         ` Kernel Apprentice
@ 2014-10-14 21:08                         ` John de la Garza
  2014-10-20  9:17                         ` el_es
  2 siblings, 0 replies; 26+ messages in thread
From: John de la Garza @ 2014-10-14 21:08 UTC (permalink / raw)
  To: kernelnewbies

On Tue, Oct 14, 2014 at 03:38:55PM +0000, Adrian Cornish wrote:
> What is wrong with you people - were you never on nntp and learned how to ignore trolls? 

This is what I have been thinking

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [PATCH] staging: Fix spacing between function name and parentheses
  2014-10-14 15:38                       ` Adrian Cornish
  2014-10-14 18:11                         ` Kernel Apprentice
  2014-10-14 21:08                         ` John de la Garza
@ 2014-10-20  9:17                         ` el_es
  2014-11-02  0:34                           ` Valdis.Kletnieks at vt.edu
  2 siblings, 1 reply; 26+ messages in thread
From: el_es @ 2014-10-20  9:17 UTC (permalink / raw)
  To: kernelnewbies

Adrian Cornish <adrianc <at> cqg.com> writes:


> I raise the simple motion that when Nicholas Krause posts - 
> NOBODY responds to him - EVER - under threat of
> torture or whatever - for whatever reason - 
> my joy of lurking here has been ruined by a single IDIOT - 
> if this was nntp he would have wandered off a long time 
> ago with ignores - but I blame this list for constantly
> responding to the TROLL and FEEDING it. DONT DO IT

Unfortunately this isn't the time of NNTP, and since lkml 
(and newbies) always was a mailing list, the only hope is
in respective peoples' killfiles...

We need to assume that the list is being watched 
not only by technically able people, but also by ones who
have just a filter for [PATCH] and don't always get
the difference between Reviewed-by and Acked-by...
AND some that could assume that no-answer to a [PATCH]
equals silent acceptance ... Or if he's con enough,
he could say, oh see all the patches I submitted,
no one ever said anything against them...

(and as Greg K-H once said, a few /accepted/ patches can make
 someone employed...) 

Maybe better to introduce a standard clear marker that
able people just respond with, to alikes of nick:

REJECTED-by: Name <address@email.server>

single line, maybe add 1 line of technical explanation 
and DO NOT react* to any further emails demanding further explanation.

(* e.g. place on kill file in your private MUA, so the only way
 they can ever get un-ignored is IFF they submit VALID patches
 to public list AND they get at least Acked.).

(Rationale:

REJECTED, because Nacked-by contains the 'acked' word...
too easy to overlook.
CAPITALS because they do stand out.

REJECTED also is clear in intent in any english<->native dictionary,

REJECTED is (IMO) also a strong enough word to not need any 
further emotional emits...

It's NOT intended in the way the April Fools like/dislike patches
on Facebook was suggested. Nothing to emotionally react to,
just a signal that THIS PATCH IS NOT GOING TO BE APPLIED.

Also it's a serious word, contrary to Trash-detected-by
or This-is-BS-by or Stay-away-from-my-list-by... 

Only to be used as 'last resort' if someone repeatedly fails
sanity test.

Because alternative is, that the mailing list(s) become invite-only,
and that is not going to happen.
)

el_es

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [PATCH] staging: Fix spacing between function name and parentheses
  2014-10-20  9:17                         ` el_es
@ 2014-11-02  0:34                           ` Valdis.Kletnieks at vt.edu
  2014-11-03 10:05                             ` Bjørn Mork
  0 siblings, 1 reply; 26+ messages in thread
From: Valdis.Kletnieks at vt.edu @ 2014-11-02  0:34 UTC (permalink / raw)
  To: kernelnewbies

On Mon, 20 Oct 2014 09:17:50 -0000, el_es said:

> Maybe better to introduce a standard clear marker that
> able people just respond with, to alikes of nick:
>
> REJECTED-by: Name <address@email.server>

We already do something like this.

You'll on occasion see 'Nacked-By: ...' go by when a kernel hacker
wants to denote their displeasure with a given patch.  It's up to the
maintainer to decide how much credence to give to the Nack, based on the
relative reputations of the person submitting the patch and the person
nacking it, and any technical grounds given with the nack.

So for instance, if Al Viro sticks a Nacked-By: on a submission, it's
going to be *really* hard to get a maintainer to accept the patch, because
Al has a very long history of almost always being right about such things.

-------------- 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/20141101/53c6e3d0/attachment.bin 

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [PATCH] staging: Fix spacing between function name and parentheses
  2014-11-02  0:34                           ` Valdis.Kletnieks at vt.edu
@ 2014-11-03 10:05                             ` Bjørn Mork
  2014-11-04  2:23                               ` nick
  0 siblings, 1 reply; 26+ messages in thread
From: Bjørn Mork @ 2014-11-03 10:05 UTC (permalink / raw)
  To: kernelnewbies

Valdis.Kletnieks at vt.edu writes:
> On Mon, 20 Oct 2014 09:17:50 -0000, el_es said:
>
>> Maybe better to introduce a standard clear marker that
>> able people just respond with, to alikes of nick:
>>
>> REJECTED-by: Name <address@email.server>
>
> We already do something like this.
>
> You'll on occasion see 'Nacked-By: ...' go by when a kernel hacker
> wants to denote their displeasure with a given patch.  It's up to the
> maintainer to decide how much credence to give to the Nack, based on the
> relative reputations of the person submitting the patch and the person
> nacking it, and any technical grounds given with the nack.
>
> So for instance, if Al Viro sticks a Nacked-By: on a submission, it's
> going to be *really* hard to get a maintainer to accept the patch, because
> Al has a very long history of almost always being right about such things.

Yes, but the technical grounds are still the reason the patch is not
accepted.  Which is why a formalized nak is pointless.  It has no value
without a verbose explanation of the technical grounds behind it. If Al
Viro, or anyone else, use a simple one-line reject message, then I am
pretty sure that is because they have already explained their objections
somewhere else. I don't think anyone can reject anything merely on their
personal reputation. And there is nowhere to record naks, so a standard
label just isn't needed.

Rejecting is completely different from e.g. Acked-by, which both is a
complete explanation ("I am fine with this patch as it is") and is
recorded for future reference in the commit message.


Bj?rn

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [PATCH] staging: Fix spacing between function name and parentheses
  2014-11-03 10:05                             ` Bjørn Mork
@ 2014-11-04  2:23                               ` nick
  0 siblings, 0 replies; 26+ messages in thread
From: nick @ 2014-11-04  2:23 UTC (permalink / raw)
  To: kernelnewbies

Greetings Bjorn and others,
I sent this patch a few weeks ago and am really trying to to improve my rep here by sending solid patches.
In addition I understand the caution with my patches due to my terrible rep but it would be nice if someone
sends or acknowledges the patch as other people on this list have stated it's correct and good in previous 
emails to me. 
Nick

On 14-11-03 05:05 AM, Bj?rn Mork wrote:
> Valdis.Kletnieks at vt.edu writes:
>> On Mon, 20 Oct 2014 09:17:50 -0000, el_es said:
>>
>>> Maybe better to introduce a standard clear marker that
>>> able people just respond with, to alikes of nick:
>>>
>>> REJECTED-by: Name <address@email.server>
>>
>> We already do something like this.
>>
>> You'll on occasion see 'Nacked-By: ...' go by when a kernel hacker
>> wants to denote their displeasure with a given patch.  It's up to the
>> maintainer to decide how much credence to give to the Nack, based on the
>> relative reputations of the person submitting the patch and the person
>> nacking it, and any technical grounds given with the nack.
>>
>> So for instance, if Al Viro sticks a Nacked-By: on a submission, it's
>> going to be *really* hard to get a maintainer to accept the patch, because
>> Al has a very long history of almost always being right about such things.
> 
> Yes, but the technical grounds are still the reason the patch is not
> accepted.  Which is why a formalized nak is pointless.  It has no value
> without a verbose explanation of the technical grounds behind it. If Al
> Viro, or anyone else, use a simple one-line reject message, then I am
> pretty sure that is because they have already explained their objections
> somewhere else. I don't think anyone can reject anything merely on their
> personal reputation. And there is nowhere to record naks, so a standard
> label just isn't needed.
> 
> Rejecting is completely different from e.g. Acked-by, which both is a
> complete explanation ("I am fine with this patch as it is") and is
> recorded for future reference in the commit message.
> 
> 
> Bj?rn
> 
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> 

^ permalink raw reply	[flat|nested] 26+ messages in thread

end of thread, other threads:[~2014-11-04  2:23 UTC | newest]

Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-10-11  1:55 [PATCH] staging: Fix spacing between function name and parentheses Nicholas Krause
2014-10-11  4:58 ` Sudip Mukherjee
2014-10-11  5:23   ` Dave Tian
2014-10-11  6:08     ` Sudip Mukherjee
2014-10-11  6:11       ` Dave Tian
2014-10-11  8:27         ` Peter Senna Tschudin
2014-10-11  9:45           ` Sudip Mukherjee
2014-10-11  9:53             ` Kristofer Hallin
2014-10-11 13:44               ` nick
2014-10-11 13:46                 ` Kristofer Hallin
2014-10-11 13:52                 ` Hugo Mills
2014-10-11 14:17                   ` nick
2014-10-11 15:25                     ` karthik nayak
2014-10-11 22:18                       ` nick
2014-10-12 22:34                   ` Valdis.Kletnieks at vt.edu
2014-10-13  2:31                     ` nick
2014-10-13  3:15                       ` Valdis.Kletnieks at vt.edu
2014-10-13  4:55                     ` Sudip Mukherjee
2014-10-14 15:38                       ` Adrian Cornish
2014-10-14 18:11                         ` Kernel Apprentice
2014-10-14 21:08                         ` John de la Garza
2014-10-20  9:17                         ` el_es
2014-11-02  0:34                           ` Valdis.Kletnieks at vt.edu
2014-11-03 10:05                             ` Bjørn Mork
2014-11-04  2:23                               ` nick
2014-10-11 14:24                 ` Robert P. J. Day

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.