| Message ID | 1402574007-13987-9-git-send-email-r.sricharan@ti.com |
|---|---|
| State | New |
| Headers | show |
On Thu, Jun 12, 2014 at 05:23:16PM +0530, Sricharan R wrote: > From: Nishanth Menon <nm@ti.com> > > remove un-necessary space in function pointer. > > Fixes checkpatch warning: > WARNING: Unnecessary space before function pointer arguments > #37: FILE: drivers/irqchip/irq-crossbar.c:37: > + void (*write) (int, int); > > WARNING: Missing a blank line after declarations > + int *register_offsets; > + void (*write)(int, int); > > WARNING: Prefer kcalloc over kzalloc with multiply > + cb->irq_map = kzalloc(max * sizeof(int), GFP_KERNEL); > > WARNING: Prefer kcalloc over kzalloc with multiply > + cb->register_offsets = kzalloc(max * sizeof(int), GFP_KERNEL); > > Signed-off-by: Nishanth Menon <nm@ti.com> > --- > drivers/irqchip/irq-crossbar.c | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c > index 5da9d36..58790d4 100644 > --- a/drivers/irqchip/irq-crossbar.c > +++ b/drivers/irqchip/irq-crossbar.c > @@ -34,7 +34,8 @@ struct crossbar_device { > uint *irq_map; > void __iomem *crossbar_base; > int *register_offsets; > - void (*write) (int, int); > + > + void (*write)(int, int); The empty line here looks bogus to me. Did you re-run checkpatch after fixing the unnecessary space to see if it still complained about having a 'blank line after declarations'? > }; > > /** > @@ -150,7 +151,7 @@ static int __init crossbar_of_init(struct device_node *node, > goto err1; > > of_property_read_u32(node, "ti,max-irqs", &max); > - cb->irq_map = kzalloc(max * sizeof(int), GFP_KERNEL); > + cb->irq_map = kcalloc(max, sizeof(int), GFP_KERNEL); > if (!cb->irq_map) > goto err2; > > @@ -176,7 +177,7 @@ static int __init crossbar_of_init(struct device_node *node, > } > } > > - cb->register_offsets = kzalloc(max * sizeof(int), GFP_KERNEL); > + cb->register_offsets = kcalloc(max, sizeof(int), GFP_KERNEL); > if (!cb->register_offsets) > goto err3; I'm generally opposed to these sorts of checkpatch patches, especially when they are just warnings. It's great for a new driver in the staging tree, but it makes backporting future bugfixes that much harder when drivers have been live in mainline. If, in the future, you're changing code in this area, go ahead and convert to kcalloc(), but I wouldn't do a separate patch for this kind of thing. Honestly, I would just drop this patch and not worry about it. thx, Jason. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Jason, On Thursday 12 June 2014 06:40 PM, Jason Cooper wrote: > On Thu, Jun 12, 2014 at 05:23:16PM +0530, Sricharan R wrote: >> From: Nishanth Menon <nm@ti.com> >> >> remove un-necessary space in function pointer. >> >> Fixes checkpatch warning: >> WARNING: Unnecessary space before function pointer arguments >> #37: FILE: drivers/irqchip/irq-crossbar.c:37: >> + void (*write) (int, int); >> >> WARNING: Missing a blank line after declarations >> + int *register_offsets; >> + void (*write)(int, int); >> >> WARNING: Prefer kcalloc over kzalloc with multiply >> + cb->irq_map = kzalloc(max * sizeof(int), GFP_KERNEL); >> >> WARNING: Prefer kcalloc over kzalloc with multiply >> + cb->register_offsets = kzalloc(max * sizeof(int), GFP_KERNEL); >> >> Signed-off-by: Nishanth Menon <nm@ti.com> >> --- >> drivers/irqchip/irq-crossbar.c | 7 ++++--- >> 1 file changed, 4 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c >> index 5da9d36..58790d4 100644 >> --- a/drivers/irqchip/irq-crossbar.c >> +++ b/drivers/irqchip/irq-crossbar.c >> @@ -34,7 +34,8 @@ struct crossbar_device { >> uint *irq_map; >> void __iomem *crossbar_base; >> int *register_offsets; >> - void (*write) (int, int); >> + >> + void (*write)(int, int); > > The empty line here looks bogus to me. Did you re-run checkpatch after > fixing the unnecessary space to see if it still complained about having > a 'blank line after declarations'? > Yes, it still complains even after fixing unnecessary space. WARNING: Missing a blank line after declarations #37: FILE: ./drivers/irqchip/irq-crossbar.c:37: + int *register_offsets; + void (*write)(int, int); >> }; >> >> /** >> @@ -150,7 +151,7 @@ static int __init crossbar_of_init(struct device_node *node, >> goto err1; >> >> of_property_read_u32(node, "ti,max-irqs", &max); >> - cb->irq_map = kzalloc(max * sizeof(int), GFP_KERNEL); >> + cb->irq_map = kcalloc(max, sizeof(int), GFP_KERNEL); >> if (!cb->irq_map) >> goto err2; >> >> @@ -176,7 +177,7 @@ static int __init crossbar_of_init(struct device_node *node, >> } >> } >> >> - cb->register_offsets = kzalloc(max * sizeof(int), GFP_KERNEL); >> + cb->register_offsets = kcalloc(max, sizeof(int), GFP_KERNEL); >> if (!cb->register_offsets) >> goto err3; > > I'm generally opposed to these sorts of checkpatch patches, especially > when they are just warnings. It's great for a new driver in the staging > tree, but it makes backporting future bugfixes that much harder when > drivers have been live in mainline. > > If, in the future, you're changing code in this area, go ahead and > convert to kcalloc(), but I wouldn't do a separate patch for this kind > of thing. > > Honestly, I would just drop this patch and not worry about it. > Ok, but i just hope that there may not be real needs to make changes for this driver in future. So if that's the case then it might be better to fix it once for now. Regards, Sricharan -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 2014-06-12 at 19:05 +0530, Sricharan R wrote: > On Thursday 12 June 2014 06:40 PM, Jason Cooper wrote: > > On Thu, Jun 12, 2014 at 05:23:16PM +0530, Sricharan R wrote: > >> diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c [] > >> @@ -34,7 +34,8 @@ struct crossbar_device { > >> uint *irq_map; > >> void __iomem *crossbar_base; > >> int *register_offsets; > >> - void (*write) (int, int); > >> + > >> + void (*write)(int, int); > > > > The empty line here looks bogus to me. Good eye. It's unnecessary. > Did you re-run checkpatch after > > fixing the unnecessary space to see if it still complained about having > > a 'blank line after declarations'? > > > Yes, it still complains even after fixing unnecessary space. It's a checkpatch defect. It's been fixed by: https://lkml.org/lkml/2014/6/6/426 > > I'm generally opposed to these sorts of checkpatch patches, especially > > when they are just warnings. It's great for a new driver in the staging > > tree, but it makes backporting future bugfixes that much harder when > > drivers have been live in mainline. Blind adherence to checkpatch isn't always a great idea. But bugfix backports haven't been much of an issue in other subsystems with fairly active whitespace/style changes. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hey Joe, On Thu, Jun 12, 2014 at 07:18:31AM -0700, Joe Perches wrote: > On Thu, 2014-06-12 at 19:05 +0530, Sricharan R wrote: > > On Thursday 12 June 2014 06:40 PM, Jason Cooper wrote: > > > On Thu, Jun 12, 2014 at 05:23:16PM +0530, Sricharan R wrote: > > >> diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c > [] > > >> @@ -34,7 +34,8 @@ struct crossbar_device { > > >> uint *irq_map; > > >> void __iomem *crossbar_base; > > >> int *register_offsets; > > >> - void (*write) (int, int); > > >> + > > >> + void (*write)(int, int); > > > > > > The empty line here looks bogus to me. > > Good eye. It's unnecessary. > > > > Did you re-run checkpatch after fixing the unnecessary space to > > > see if it still complained about having a 'blank line after > > > declarations'? > > > > > Yes, it still complains even after fixing unnecessary space. > > It's a checkpatch defect. > > It's been fixed by: > https://lkml.org/lkml/2014/6/6/426 Ah, good to know. > > > I'm generally opposed to these sorts of checkpatch patches, especially > > > when they are just warnings. It's great for a new driver in the staging > > > tree, but it makes backporting future bugfixes that much harder when > > > drivers have been live in mainline. > > Blind adherence to checkpatch isn't always a great idea. Agreed. > But bugfix backports haven't been much of an issue in > other subsystems with fairly active whitespace/style > changes. Most of the mvebu fixes we've had that failed to apply were generally due to a large whitespace change (dts node shuffling, admittedly not checkpatch-related). I've also frequently been stymied by code cleanups when using git blame to find the commit introducing a regression. So, my general rule is: If you're submitting a patch to make checkpatch be quiet, re-assess the need. If you're making changes and you can fix some checkpatch items while you're there, then do so. There are certainly legitimate checkpatch-only patches, I just don't think this is one qualifies. thx, Jason. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
On Thu, 2014-06-12 at 11:32 -0400, Jason Cooper wrote: Hi Jason. > > But bugfix backports haven't been much of an issue in > > other subsystems with fairly active whitespace/style > > changes. > > Most of the mvebu fixes we've had that failed to apply were generally > due to a large whitespace change (dts node shuffling, admittedly not > checkpatch-related). So not due to this. > I've also frequently been stymied by code cleanups > when using git blame to find the commit introducing a regression. git blame -w can frequently help there. > So, my general rule is: If you're submitting a patch to make checkpatch > be quiet, re-assess the need. If you're making changes and you can fix > some checkpatch items while you're there, then do so. Decent rule. > There are certainly legitimate checkpatch-only patches, I just don't > think this is one qualifies. Of course it's the maintainer's choice (and last I saw, that's you) to ignore whatever doesn't fit the appropriate vision for the code. $ ./scripts/get_maintainer.pl -f drivers/irqchip/irq-crossbar.c Thomas Gleixner <tglx@linutronix.de> (maintainer:IRQCHIP DRIVERS) Jason Cooper <jason@lakedaemon.net> (maintainer:IRQCHIP DRIVERS) ... cheers, Joe -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Jason, On Thursday 12 June 2014 09:35 PM, Joe Perches wrote: > On Thu, 2014-06-12 at 11:32 -0400, Jason Cooper wrote: > > Hi Jason. > >>> But bugfix backports haven't been much of an issue in >>> other subsystems with fairly active whitespace/style >>> changes. >> >> Most of the mvebu fixes we've had that failed to apply were generally >> due to a large whitespace change (dts node shuffling, admittedly not >> checkpatch-related). > > So not due to this. > >> I've also frequently been stymied by code cleanups >> when using git blame to find the commit introducing a regression. > > git blame -w can frequently help there. > >> So, my general rule is: If you're submitting a patch to make checkpatch >> be quiet, re-assess the need. If you're making changes and you can fix >> some checkpatch items while you're there, then do so. > > Decent rule. > >> There are certainly legitimate checkpatch-only patches, I just don't >> think this is one qualifies. > > Of course it's the maintainer's choice (and last I saw, > that's you) to ignore whatever doesn't fit the appropriate > vision for the code. > > $ ./scripts/get_maintainer.pl -f drivers/irqchip/irq-crossbar.c > Thomas Gleixner <tglx@linutronix.de> (maintainer:IRQCHIP DRIVERS) > Jason Cooper <jason@lakedaemon.net> (maintainer:IRQCHIP DRIVERS) Ok, if this is not qualifying as a separate patch then i will merge this with other patches in the series which touch them. Regards, Sricharan -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Jun 13, 2014 at 12:00:31PM +0530, Sricharan R wrote: > Ok, if this is not qualifying as a separate patch then i will merge > this with other patches in the series which touch them. A good general rule of thumb is to just run checkpatch on the patches, not the source files. This way, we prevent new warnings from being introduced, and we can cleanup stuff in the immediate vicinity to code we are already changing. thx, Jason. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c index 5da9d36..58790d4 100644 --- a/drivers/irqchip/irq-crossbar.c +++ b/drivers/irqchip/irq-crossbar.c @@ -34,7 +34,8 @@ struct crossbar_device { uint *irq_map; void __iomem *crossbar_base; int *register_offsets; - void (*write) (int, int); + + void (*write)(int, int); }; /** @@ -150,7 +151,7 @@ static int __init crossbar_of_init(struct device_node *node, goto err1; of_property_read_u32(node, "ti,max-irqs", &max); - cb->irq_map = kzalloc(max * sizeof(int), GFP_KERNEL); + cb->irq_map = kcalloc(max, sizeof(int), GFP_KERNEL); if (!cb->irq_map) goto err2; @@ -176,7 +177,7 @@ static int __init crossbar_of_init(struct device_node *node, } } - cb->register_offsets = kzalloc(max * sizeof(int), GFP_KERNEL); + cb->register_offsets = kcalloc(max, sizeof(int), GFP_KERNEL); if (!cb->register_offsets) goto err3;