linux-kernel - Re: [RFC PATCH 0/5] add gpio_chip

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <201404221617.43272.arnd@arndb.de>
Date:	Tue, 22 Apr 2014 16:17:42 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Javier Martinez Canillas <javier@...hile0.org>
Cc:	Linus Walleij <linus.walleij@...aro.org>,
	Javier Martinez Canillas <javier.martinez@...labora.co.uk>,
	Alexandre Courbot <acourbot@...dia.com>,
	Mika Westerberg <mika.westerberg@...ux.intel.com>,
	Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
	Santosh Shilimkar <santosh.shilimkar@...com>,
	Kevin Hilman <khilman@...aro.org>,
	"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
	"Linux-OMAP" <linux-omap@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 0/5] add gpio_chip_ops to hold GPIO operations

On Tuesday 22 April 2014, Javier Martinez Canillas wrote:
> Hello Linus,
> 
> On Tue, Apr 22, 2014 at 1:36 PM, Linus Walleij <linus.walleij@...aro.org> wrote:
> > On Tue, Apr 8, 2014 at 8:20 PM, Javier Martinez Canillas
> > <javier.martinez@...labora.co.uk> wrote:
> >
> >> So this is an RFC patch-set to add a virtual table to be used by
> >> GPIO chip controllers and consist of the following patches:
> >
> > Overall I like this.

Agreed, it's a very good cleanup.

> > However I don't want to see any transitional phase. I prefer a BIG
> > fat patch converting everyone and its dog to the new vtable and
> > removing the old function pointers. This can be based on the HEAD
> > of my GPIO devel branch.
> >
> 
> Ok, I was adding a commit per GPIO driver but the patch-set would have
> been very big (~200 patches).
> 
> > It may be a good idea to use coccinelle for this refactoring in order
> > not to miss any users.
> >
> 
> Agreed, I was manually searching for users by using grep but I agree
> that is much safer to use coccinelle for this. I don't have previous
> experience writing coccinelle semantics patches though so it may take
> more time than I thought but it is the perfect excuse to finally learn
> how to do it :-)

I'm not a big fan of doing this all at once, but it's not my call here.
Just one recommendation: if you can't do an obvious coccinelle patch
to do everything at once, use extra patches in the beginning to clean
up the code enough to make it work, then have the large patch fully
automated.

	Arnd
--
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/