[PATCH V2 08/19] irqchip: crossbar: fix checkpatch warning

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:

quoted

On Thursday 12 June 2014 06:40 PM, Jason Cooper wrote:

quoted

On Thu, Jun 12, 2014 at 05:23:16PM +0530, Sricharan R wrote:

quoted

diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c

[]

quoted

quoted

quoted

@@ -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.

quoted

quoted

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.

quoted

quoted

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.