lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 12 Jun 2014 11:32:26 -0400 From: Jason Cooper <jason@...edaemon.net> To: Joe Perches <joe@...ches.com> Cc: Sricharan R <r.sricharan@...com>, linux-omap@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, tony@...mide.com, santosh.shilimkar@...com, nm@...com, rnayak@...com, linux@....linux.org.uk, tglx@...utronix.de Subject: Re: [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: > > 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@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists