* [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 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
* [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
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.