[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1376061267.2087.91.camel@joe-AO722>
Date: Fri, 09 Aug 2013 08:14:27 -0700
From: Joe Perches <joe@...ches.com>
To: Peter Senna Tschudin <peter.senna@...il.com>
Cc: Kumar Gaurav <kumargauravgupta3@...il.com>,
David Miller <davem@...emloft.net>,
Dan Carpenter <dan.carpenter@...cle.com>, emilio@...pez.com.ar,
mugunthanvnm@...com, jg1.han@...sung.com,
hsweeten@...ionengravers.com, netdev <netdev@...r.kernel.org>,
kernel-janitors@...r.kernel.org
Subject: Re: [PATCH] net:ethernet:korina.c Removed IRQF_DISABLED
On Fri, 2013-08-09 at 15:15 +0200, Peter Senna Tschudin wrote:
> Coccinelle (http://coccinelle.lip6.fr/) can help you in this task. The
> semantic patch below takes care of both cases for you:
Hi Peter & Kumar
Coccinelle (aka: spatch) is a good/great way to do this.
(btw Peter, your email was whitespace damaged)
Peter's useful conversion won't find/convert cases where
IRQF_DISABLED is used in a #define like:
> diff --git a/drivers/net/ethernet/micrel/ks8851_mll.c b/drivers/net/ethernet/micrel/ks8851_mll.c
> []
> @@ -915,7 +915,7 @@ static int ks_net_open(struct net_device *netdev)
> []
> -#define KS_INT_FLAGS (IRQF_DISABLED|IRQF_TRIGGER_LOW)
> +#define KS_INT_FLAGS (IRQF_TRIGGER_LOW)
You'd still have to do those by hand.
Also, it's good to just do the direct conversions/renames
so that it's easy to verify just a single attribute has
been changed by the patches.
There are tools like Dan Carpenter's rename_review.pl
https://lkml.org/lkml/2011/7/19/196
that can help you verify the patches.
These patches will generate different objects than the
original codes. Otherwise, it's good to make sure that for
whitespace only/style patches, the objects are unchanged.
Make the patch that removes the IRQF_DISABLED #define
last in the series and maybe do not even submit it until a
few weeks after all the other patches are accepted.
Lastly, it might also be good to reflow the modified code
to maximally fill to 80 columns where reasonable. This can
both make the code a bit more human readable and reduce the
overall line count.
Just remember it's generally better to do any code reflow
in a separate patch. To me the criteria for combining
is how large the rename patch is. Smallish, ok to reflow,
largish, not ok. Use your taste as appropriate.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists