From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753417AbcGUQpk (ORCPT ); Thu, 21 Jul 2016 12:45:40 -0400 Received: from host.buserror.net ([209.198.135.123]:35761 "EHLO host.buserror.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753286AbcGUQpi (ORCPT ); Thu, 21 Jul 2016 12:45:38 -0400 Message-ID: <1469119526.25630.42.camel@buserror.net> From: Scott Wood To: Michael Ellerman , Arnd Bergmann Cc: linux-mmc@vger.kernel.org, devicetree@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, Yangbo Lu Date: Thu, 21 Jul 2016 11:45:26 -0500 In-Reply-To: <146909676646.16700.8383344640490662952@concordia> References: <1468723822-30457-1-git-send-email-oss@buserror.net> <1468723822-30457-5-git-send-email-oss@buserror.net> <4016699.uYaV8nWfqC@wuerfel> <1469039508.25630.17.camel@buserror.net> <146909676646.16700.8383344640490662952@concordia> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.18.5.2-0ubuntu3 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 75.72.173.242 X-SA-Exim-Mail-From: oss@buserror.net X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * -15 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] Subject: Re: [PATCH v11 4/5] powerpc/fsl: move mpc85xx.h to include/linux/fsl X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:57:07 +0000) X-SA-Exim-Scanned: Yes (on host.buserror.net) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2016-07-21 at 20:26 +1000, Michael Ellerman wrote: > Quoting Scott Wood (2016-07-21 04:31:48) > > > > On Wed, 2016-07-20 at 13:24 +0200, Arnd Bergmann wrote: > > > > > > On Saturday, July 16, 2016 9:50:21 PM CEST Scott Wood wrote: > > > > > > > > > > > > From: yangbo lu > > > > > > > > Move mpc85xx.h to include/linux/fsl and rename it to svr.h as a common > > > > header file.  This SVR numberspace is used on some ARM chips as well > > > > as > > > > PPC, and even to check for a PPC SVR multi-arch drivers would > > > > otherwise > > > > need to ifdef the header inclusion and all references to the SVR > > > > symbols. > > > > > > > > Signed-off-by: Yangbo Lu > > > > Acked-by: Wolfram Sang > > > > Acked-by: Stephen Boyd > > > > Acked-by: Joerg Roedel > > > > [scottwood: update description] > > > > Signed-off-by: Scott Wood > > > > > > > As discussed before, please don't introduce yet another vendor specific > > > way to match a SoC ID from a device driver. > > > > > > I've posted a patch for an extension to the soc_device infrastructure > > > to allow comparing the running SoC to a table of devices, use that > > > instead. > > As I asked before, in which relevant maintainership capacity are you > > NACKing > > this? > I'll nack the powerpc part until you guys can agree. OK, I've pulled these patches out. For the MMC issue I suggest using ifdef CONFIG_PPC and mfspr(SPRN_SVR) like the clock driver does[1] and we can revisit the issue if/when we need to do something similar on an ARM chip. -Scott [1] One of the issues with Arnd's approach is that it wouldn't have worked for early things like the clock driver, and he didn't seem to mind using ifdef and mfspr() there.