Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936473AbcCQRHG (ORCPT ); Thu, 17 Mar 2016 13:07:06 -0400 Received: from mout.kundenserver.de ([217.72.192.74]:64682 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934314AbcCQRHA convert rfc822-to-8bit (ORCPT ); Thu, 17 Mar 2016 13:07:00 -0400 From: Arnd Bergmann To: Rob Herring Cc: Scott Wood , 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 Date: Thu, 17 Mar 2016 18:06:09 +0100 Message-ID: <3706958.XeRFmKM0K5@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <20160317170101.GA21009@rob-hp-laptop> References: <1457518131-11339-1-git-send-email-yangbo.lu@nxp.com> <20160317170101.GA21009@rob-hp-laptop> MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT Content-Type: text/plain; charset="utf-8" X-Provags-ID: V03:K0:xoVFYSevLC4mbE0i2xdZht8j3Li4TME2jjRYB6uHDU2q5tJ0oYj 0qt85W3BxItIhaAj5Fd/DSXZUmk8ya6oWpbIqs+ZXYLaeZuTHtD3jbY0Tg2iwXU1gSGcTVY krBfmCz0tRw0H7mlTCkxxs5Ts/TJXZltRzU2lfKb385whNURb3vMePquNDpaH8NLgJSmuSc UmMrlY/MLo4gVoi0xMCbQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:TVC/gV8pU6Y=:HW/wjyHslawAkVLkD8oDz/ mBjmaWwydiQFeWKu0MbqfzNPTMFfK1bUCa9uQYssnp2FrEOrItipkQK6+7TPlc2nDXcYv+qV7 6spxKEVhlHftO9Ncfu8m8OsjnsK/jR39y2Iyw4BaccLqEVfAHMO8dAyFj6gbve/vB7a0BEiEK HIE6h4M+gwuf+0Z5OLOOOhIVseFwOuj4aCwzAV/rMaMLIC2gp5ndCKH0l/TZtVElUTVYvlFma tWoWMK+dmLHiYFS5KicGY2UdgU708+KfRPc3yvMiih7pVbhHrKUWOfiAAQsVhEsloJyfWyGNe +f7MFLHqtMae6lJZ07fRJ3mQIwzDOrjKg9botTVOxFScdVY766LXrOdJy5w+u/eMmUGIJeLw4 4uuf1spQ1hKM9ewR1n+jdyn2zpsvpXaNT94NYtpcuo+4L3u1N7bBKRxDBwa5P4F/RbfXnnGPq ik2MC0Z6w3tdH8kql2PkZZCENrTAcAMN6ZJ1faO2Wj7QEyoyaB2knmdnvGcQP2c+ggo0nZKeC 4jxJqK7D1y8nmYvPvQpxb11WJt9oeCt8sk0wv+ZJkCxN3k4lxjzYT1iEdSijvQa1fC+hvhwUw VoHKuNxCcg2OZU9t7WrpXFMh3WTkJx31MJ0QwxGUc6AJXjSb4CjlYbEgKn+u6fPP9Q0D41W0w ePxLzizTV8onYz1I56lt1dBDxM+lgi2aMv/1qykvJ8WBCXLi4JBn5CZVXwqK4UsI8tD5YUwmo xjWRpSVQKMejNOHI Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1819 Lines: 40 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. 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. > 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. Arnd