Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932471Ab3CLMKz (ORCPT ); Tue, 12 Mar 2013 08:10:55 -0400 Received: from moutng.kundenserver.de ([212.227.17.10]:61882 "EHLO moutng.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752285Ab3CLMKx (ORCPT ); Tue, 12 Mar 2013 08:10:53 -0400 From: Arnd Bergmann To: Alexandre Courbot Subject: Re: [RFC 17/17] unicore32: default GENERIC_GPIO to false Date: Tue, 12 Mar 2013 12:10:29 +0000 User-Agent: KMail/1.12.2 (Linux/3.8.0-8-generic; KDE/4.3.2; x86_64; ; ) Cc: Ralf Baechle , Chris Zankel , Guan Xuetao , Kumar Gala , acourbot@nvidia.com, Jonas Bonn , Haavard Skinnemoen , Vitaly Bordug , Linus Walleij , Grant Likely , Josh Boyer , "Hans-Christian Egtvedt" , Linux Kernel Mailing List , Mike Frysinger , Paul Mundt , Geert Uytterhoeven , Matt Porter , Benjamin Herrenschmidt , Marcelo Tosatti , Paul Mackerras , Max Filippov , Russell King References: <1363083150-30964-1-git-send-email-acourbot@nvidia.com> <201303121118.55770.arnd@arndb.de> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201303121210.29613.arnd@arndb.de> X-Provags-ID: V02:K0:z12z8rrKtEV3eoIQyU5Tj7DK6uJjeJ9X0QKjUAw3hBs ycnozjoIJ1h7SWE97QVe3gybENfn7OILPedzCYD5l999GeJQMC NuCK08Z7rNjqMuEly81SDrLr+OfxONUqHeEeE/yjNOGZpoI1G9 evjggSl8DIVXUHnc1rEouM4AjPxY5rxUE79FjzU/B9Tq0mKGQL SzhrEo2cqPwF41Geb85qH/57j3FP7SxUQAMGMt/bdanvLfyiL9 0HPJuv7GP1uRpe6Q1RX29Vc63j+NnKbNSUgGnbC8kQOdB721Sr SRC3Wy4Pjt0VmPwea1VO5vv7XjsIgNbq4N9Q6o0ILk31hn978S ZHJ9Y4U4Qow8m72WXrss= Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1018 Lines: 22 On Tuesday 12 March 2013, Alexandre Courbot wrote: > Thanks, I will fix this in the next version. > > Btw, if this (or rather the next iteration) gets merged, may I suggest to > do it through the GPIO tree instead of having each architecture picking the > patches of relevance. A considerable number of other patches that depend on > this will follow and this will ensure they are picked in the right order. Sounds reasonable, but I would also suggest you prepare a branch that can get merged into the GPIO, ARM, PowerPC and MIPS trees to avoid merge conflicts in that case, since these all will have a number of changes conflicting with yours. In the end, I would not care which tree it gets merged through, as long as all have the same version of your patches. Arnd -- 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/