Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756046AbcCRS2O (ORCPT ); Fri, 18 Mar 2016 14:28:14 -0400 Received: from mail-am1on0066.outbound.protection.outlook.com ([157.56.112.66]:2912 "EHLO emea01-am1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754889AbcCRS2K convert rfc822-to-8bit (ORCPT ); Fri, 18 Mar 2016 14:28:10 -0400 From: Scott Wood To: Arnd Bergmann , Rob Herring CC: Yangbo Lu , "linuxppc-dev@lists.ozlabs.org" , "devicetree@vger.kernel.org" , "ulf.hansson@linaro.org" , Zhao Qiang , Russell King , Bhupesh Sharma , "netdev@vger.kernel.org" , Joerg Roedel , Kumar Gala , "linux-mmc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Yang-Leo Li , "iommu@lists.linux-foundation.org" , "linux-i2c@vger.kernel.org" , Claudiu Manoil , Santosh Shilimkar , Xiaobo Xie , "linux-clk@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" Subject: Re: [v6, 5/5] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0 Thread-Topic: [v6, 5/5] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0 Thread-Index: AQHRee0YIn8/QV1m10iEkCQyCHYnAg== Date: Fri, 18 Mar 2016 18:28:05 +0000 Message-ID: References: <1457518131-11339-1-git-send-email-yangbo.lu@nxp.com> <20160317170101.GA21009@rob-hp-laptop> <3706958.XeRFmKM0K5@wuerfel> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: arndb.de; dkim=none (message not signed) header.d=none;arndb.de; dmarc=none action=none header.from=nxp.com; x-originating-ip: [2601:448:8100:702f:12bf:48ff:fe84:c9a0] x-ms-office365-filtering-correlation-id: 95856c71-79f4-4de2-12e0-08d34f5b0c4b x-microsoft-exchange-diagnostics: 1;VI1PR04MB0895;5:4RH5SV2GvmSqiIBxotMRQ+XkzR4MPY/QeHBbLSGtV8vi9K0095WVoAw3aYf6Lo+THZHTY3B4sXSlCvZk+imx8cF95U0i/GpTf2M4TSWb+abHyX5NnveFsvxBLfAIchytsFu/3SWrBG+lOAFDplgywA==;24:WdTmkPinbroFDm8jhDc4LdkTX0ieLN7tWGl5YOPj6HKuPqBKE2Re5r8C3+9k8nro55gKZw8//2240Thf+VjLWy2BQBVUIoW9pBewfbtdrAg= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR04MB0895; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001);SRVR:VI1PR04MB0895;BCL:0;PCL:0;RULEID:;SRVR:VI1PR04MB0895; x-forefront-prvs: 088552DE73 x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(6009001)(24454002)(43544003)(377454003)(586003)(2900100001)(6116002)(102836003)(81166005)(50986999)(86362001)(76176999)(33656002)(54356999)(74316001)(1220700001)(5002640100001)(106116001)(76576001)(230783001)(3280700002)(5003600100002)(87936001)(5004730100002)(15975445007)(77096005)(1096002)(4326007)(189998001)(122556002)(10400500002)(19580395003)(3660700001)(93886004)(5008740100001)(2906002)(92566002)(5001770100001)(7059030)(3826002);DIR:OUT;SFP:1101;SCL:1;SRVR:VI1PR04MB0895;H:DB5PR0401MB1928.eurprd04.prod.outlook.com;FPR:;SPF:None;MLV:sfv;LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Mar 2016 18:28:05.4361 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB0895 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2566 Lines: 55 On 03/17/2016 12:06 PM, Arnd Bergmann wrote: > On Thursday 17 March 2016 12:01:01 Rob Herring wrote: >> On Mon, Mar 14, 2016 at 05:45:43PM +0000, Scott Wood wrote: > >>>>> This makes the driver non-portable. Better identify the specific >>>>> workarounds based on the compatible string for this device, or add a >>>>> boolean DT property for the quirk. >>>>> >>>>> Arnd >>>> >>>> [Lu Yangbo-B47093] Hi Arnd, we did have a discussion about using DTS in v1 before. >>>> https://patchwork.kernel.org/patch/6834221/ >>>> >>>> We don?t have a separate DTS file for each revision of an SOC and if we did, we'd constantly have people using the wrong one. >>>> In addition, the device tree is stable ABI and errata are often discovered after device tree are deployed. >>>> See the link for details. >>>> >>>> So we decide to read SVR from the device-config/guts MMIO block other than using DTS. >>>> Thanks. >>> >>> Also note that this driver is already only for fsl-specific hardware, >>> and it will still work even if fsl_guts doesn't find anything to bind to >>> -- it just wouldn't be able to detect errata based on SVR in that case. >> >> IIRC, it is the same IP block as i.MX and Arnd's point is this won't >> even compile on !PPC. It is things like this that prevent sharing the >> driver. The whole point of using the MMIO SVR instead of the PPC SPR is so that it will work on ARM... The guts driver should build on any platform as long as OF is enabled, and if it doesn't find a node to bind to it will return 0 for SVR, and the eSDHC driver will continue (after printing an error that should be removed) without the ability to test for errata based on SVR. > I think the first four patches take care of building for ARM, > but the problem remains if you want to enable COMPILE_TEST as > we need for certain automated checking. What specific problem is there with COMPILE_TEST? >> Dealing with Si revs is a common problem. We should have a >> common solution. There is soc_device for this purpose. > > Exactly. The last time this came up, I think we agreed to implement a > helper using glob_match() on the soc_device strings. Unfortunately > this hasn't happened then, but I'd still prefer that over yet another > vendor-specific way of dealing with the generic issue. soc_device would require encoding the SVR as a string and then decoding the string, which is more complicated and error prone than having platform-specific code test a platform-specific number. And when would it get registered on arm64, which doesn't have platform code? -Scott