From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755336AbcHCDeR (ORCPT ); Tue, 2 Aug 2016 23:34:17 -0400 Received: from mail-db5eur01on0088.outbound.protection.outlook.com ([104.47.2.88]:59232 "EHLO EUR01-DB5-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752905AbcHCDeI (ORCPT ); Tue, 2 Aug 2016 23:34:08 -0400 From: Yangbo Lu To: Ulf Hansson CC: "linux-mmc@vger.kernel.org" , "devicetree@vger.kernel.org" , "linuxppc-dev@lists.ozlabs.org" , "linux-kernel@vger.kernel.org" , Xiaobo Xie , Scott Wood , Michael Ellerman , Arnd Bergmann Subject: RE: [PATCH v11 4/5] powerpc/fsl: move mpc85xx.h to include/linux/fsl Thread-Topic: [PATCH v11 4/5] powerpc/fsl: move mpc85xx.h to include/linux/fsl Thread-Index: AQHR39X+fUuOKF87rkW1WMo/w0++X6AhMsAAgAB3hwCAAQqhAIAAafwAgAWVieCAAsoqAIAJkVQwgAE9c4CAAFioUA== Date: Wed, 3 Aug 2016 03:33:38 +0000 Message-ID: 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> <1469119526.25630.42.camel@buserror.net> <1469579882.25630.168.camel@buserror.net> <1470174043.25630.233.camel@buserror.net> In-Reply-To: <1470174043.25630.233.camel@buserror.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=yangbo.lu@nxp.com; x-originating-ip: [199.59.230.102] x-ms-office365-filtering-correlation-id: 8f50bc0a-0cb9-48cc-0c5b-08d3bb4ef53b x-microsoft-exchange-diagnostics: 1;HE1PR04MB0889;6:Te5MJxsW6rANeVBvUXWsFp1Q8EPk35YZ4CnbEtzhQ+9g7P+g78Y0gS5F55QCcW6bh15u5LKDboxSKxeYqWb/lNfqHimyTC0JaBjfito6ve2z3GeFK2WU+V1ne/c6diT++NVII7rMS9Pq7e/ekEjkSKIKLu1SdMo6AwwHunsTsMaUNNQJSLInrZO0fhg27vGkfjigcAtY3DroWRGJRGUwUdgrzxMamLNlDR7vao/G119BKq+RVFl47Ten02XyWj7AiDLIPpIqPnjm4mvQ2kZ70FTTrxCgwyDcY0QhO1M+xUnOhgaOCsVoTTP2kSunrh87wZISA/8IaqgIRnSgJEU4wQ==;5:BYhDT2pImdGE78/pHHa1/yi8sqf+BSDQ3r/m5iGCCeUWUThbFnqeMbs/xfFOeL5WSU7M6pOWor9cCoMpSpoP25Y4iqs0DDOd30Ped+JSCl5l0BGghzZJD/EVXd8fUWtiJFd31CXQqBJVSgWaOYw1xQ==;24:miFh174I+gKzJ4HgU2JsKnNip5Wux4ucSr6Ls6sj0/9yLlHvyacHk4HQ5gWf9iUhqfxraLnEAkGUsF2qazasFd6Y+LKEsi+TLTcAZUHfxz4=;7:veMkQTpBEyc7bMLChAfCu/MH7EG8nB9bi95cWhJEjbjbrFJ292NfQBVW3WhL5q/N2ptFnruwBIJ8tsVokVaBScIoY4hM7D5nRlPGFaqqiMxKF1JSaFLsGfm14z2JlXSnGSZu8sleRJuWWOH9zvkNRFl1vNMt/JIoA7ZF3dHlV+pDAGeFtJ4ca5jGaw49wm9g1ww95yPmy+xaH5HcuNucDKeqZyKBpT4Uyznd6Kl5q23vZkZ7cfD01SnIELSzWikG x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR04MB0889; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(9452136761055)(65623756079841)(185117386973197); x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026);SRVR:HE1PR04MB0889;BCL:0;PCL:0;RULEID:;SRVR:HE1PR04MB0889; x-forefront-prvs: 00235A1EEF x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(6009001)(7916002)(13464003)(377454003)(377424004)(24454002)(52314003)(189002)(199003)(5002640100001)(122556002)(19580405001)(586003)(2906002)(76576001)(19580395003)(87936001)(66066001)(3280700002)(106356001)(3660700001)(102836003)(106116001)(6116002)(92566002)(3846002)(76176999)(4326007)(33656002)(81166006)(77096005)(10400500002)(97736004)(305945005)(9686002)(54356999)(68736007)(86362001)(110136002)(2900100001)(7846002)(8936002)(2950100001)(101416001)(93886004)(8676002)(74316002)(7736002)(81156014)(189998001)(105586002)(7696003)(50986999);DIR:OUT;SFP:1101;SCL:1;SRVR:HE1PR04MB0889;H:HE1PR04MB0889.eurprd04.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2016 03:33:38.3351 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR04MB0889 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id u733YLx1029885 Hi Uffe, > -----Original Message----- > From: Scott Wood [mailto:oss@buserror.net] > Sent: Wednesday, August 03, 2016 5:41 AM > To: Yangbo Lu; Michael Ellerman; Arnd Bergmann; Ulf Hansson > Cc: linux-mmc@vger.kernel.org; devicetree@vger.kernel.org; linuxppc- > dev@lists.ozlabs.org; linux-kernel@vger.kernel.org; Xiaobo Xie > Subject: Re: [PATCH v11 4/5] powerpc/fsl: move mpc85xx.h to > include/linux/fsl > > On Tue, 2016-08-02 at 05:57 +0000, Yangbo Lu wrote: > > Hi Scott, > > > > > > > > -----Original Message----- > > > From: Scott Wood [mailto:oss@buserror.net] > > > Sent: Wednesday, July 27, 2016 8:38 AM > > > To: Yangbo Lu; Michael Ellerman; Arnd Bergmann; Ulf Hansson > > > Cc: linux-mmc@vger.kernel.org; devicetree@vger.kernel.org; linuxppc- > > > dev@lists.ozlabs.org; linux-kernel@vger.kernel.org > > > Subject: Re: [PATCH v11 4/5] powerpc/fsl: move mpc85xx.h to > > > include/linux/fsl > > > > > > On Mon, 2016-07-25 at 06:12 +0000, Yangbo Lu wrote: > > > > > > > > Hi Scott, > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Scott Wood [mailto:oss@buserror.net] > > > > > Sent: Friday, July 22, 2016 12:45 AM > > > > > 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 > > > > > Subject: Re: [PATCH v11 4/5] powerpc/fsl: move mpc85xx.h to > > > > > include/linux/fsl > > > > > > > > > > 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. > > > > [Lu Yangbo-B47093] I remembered that Uffe had opposed us to > > > > introduce > > > > non- generic header files(like '#include ') in mmc > > > > driver initially. So I think it will not be accepted to use ifdef > > > > CONFIG_PPC and mfspr(SPRN_SVR)... > > > > And this method still couldn’t get SVR of ARM chip now. > > > Right, as I said we'll have to revisit the issue if/when we have the > > > same problem on an ARM chip.  That also applies if the PPC ifdef is > > > still getting NACKed from the MMC side. > > [Lu Yangbo-B47093] It's not clear for me about your idea :( Do you > > mean we can still use this method, or not ? > > I think Uffe had opposed to use ifdef CONFIG_PPC and mfspr(SPRN_SVR). > > Is there any solution to resolve ? > > :) > > As I said, I'm OK with using the SPR.  It's up to you to find out whether > it's still unacceptable with the MMC maintainers given all the discussion > (it would be the quickest way to get the workaround enabled), or just go > with the method below. [Lu Yangbo-B47093] As you know, this patchset(as below) has been discussed for more than one year. What I want is just to add a fix for an specific soc revision. Yangbo Lu (7): Documentation: DT: update Freescale DCFG compatible ARM64: dts: ls2080a: add device configuration node soc: fsl: add GUTS driver for QorIQ platforms dt: move guts devicetree doc out of powerpc directory powerpc/fsl: move mpc85xx.h to include/linux/fsl MAINTAINERS: add entry for Freescale SoC drivers mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0 But we have to abandon it since Arnd strongly disagree our guts driver method to get soc revision. Now I have to ask you to reconsider the original method to get soc revison since we really have no better idea. As Scott suggested above, use ifdef CONFIG_PPC and mfspr(SPRN_SVR) like the clock driver does to get SVR. It's quickest way to resolve our esdhc issue. Could you reconsider to use this? Although Arnd provided another new method by sending a proof-of-concept patch as below, there were still many controversial points. I'm worried that would be discussed for a quite long time like the guts driver. [PATCH 1/4] base: soc: introduce soc_device_match() interface [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms [PATCH 3/4] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0 [PATCH 4/4] Revert "powerpc/fsl: Move fsl_guts.h out of arch/powerpc" Anyway, what I want is just to fix the esdhc issue ASAP. Uffe, Could you reconsider whether you could accept the way using ifdef CONFIG_PPC and mfspr(SPRN_SVR)? Or do you have any suggestion. I will appreciate your suggestion. Thanks a lot. - Yangbo > > > > > Any other suggestion here? > > > The other option is to try to come up with something that fits into > > > Arnd's framework while addressing the concerns I raised.  The soc_id > > > string should be well-structured to avoid mismatches and > > > compatibility problems (especially since it would get exposed to > > > userspace).  Maybe something like: > > > > > > svr:,svre:,name: > > name>,die:,rev:X.Y,,,<...>, > > [Lu Yangbo-B47093] The soc_device_attribut struct is defined as below. > > struct soc_device_attribute { > >         const char *machine; > >         const char *family; > >         const char *revision; > >         const char *soc_id; > > }; > > > > We can put the 'model' in root node of dts as machine, put 'Freescale > QorIQ' > > as family, > > I'd just put "QorIQ" to avoid the question of whether to use "Freescale" > or "NXP". > > > and put x.x as revision. Is it ok? > > As you suggested, you like to use below string as soc_id. It's easy to > > get svr, but how does the software know the name and die, and put them > > into this string ? It's a large code to define them. > > Yes, there would need to be a table in the guts driver for each SVR.  If > the SVR isn't found in the table then the soc_id would only contain the > svr: and > svre: fields. > > > > > > > svr:,svre:,name: > > name>,die:,rev:X.Y,,,<...>, > > Should we remove rev here since there is also a revision member? > > Yes, I forgot there was a revision field -- it should go there obviously. > > > Regarding the guts_init, we still call guts_init and then match the > > soc, or we change to use platform driver? > > Or do you know any better place to call guts_init to initialize only > once? > > Use a platform driver for now.  If we ever need to check an ARM SVR in > the clock driver or similar place, then Arnd can explain what he wants us > to do then :-) > > -Scott