From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from moutng.kundenserver.de ([212.227.17.10]:54171 "EHLO moutng.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753740Ab3G2MF7 (ORCPT ); Mon, 29 Jul 2013 08:05:59 -0400 Date: Mon, 29 Jul 2013 14:05:53 +0200 (CEST) From: Guennadi Liakhovetski Subject: Re: [PATCH 1/2] mmc: add Device Tree properties for UHS modes In-Reply-To: <1375098159.3340.29.camel@hornet> Message-ID: References: <51F2ADA2.2030503@wwwdotorg.org> <51F2EBD4.1060603@wwwdotorg.org> <1375095053.3340.7.camel@hornet> <1375098159.3340.29.camel@hornet> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: devicetree-owner@vger.kernel.org To: Pawel Moll Cc: Stephen Warren , "linux-sh@vger.kernel.org" , "linux-mmc@vger.kernel.org" , Magnus Damm , Chris Ball , "devicetree@vger.kernel.org" , Simon Horman , Ian Campbell , Mark Rutland , "rob.herring@calxeda.com" List-ID: On Mon, 29 Jul 2013, Pawel Moll wrote: > On Mon, 2013-07-29 at 12:27 +0100, Guennadi Liakhovetski wrote: > > On Mon, 29 Jul 2013, Pawel Moll wrote: > > > > > On Mon, 2013-07-29 at 08:18 +0100, Guennadi Liakhovetski wrote: > > > > A short addendum. At least with Renesas SoCs I see the situation in the > > > > following way: new SoC versions appear relatively frequently. > > > > > > What frequency are we talking about? Once per year? Once per month? I'm > > > not trying to be picky, it really makes a difference... > > > > Definitely not every month - not until now in the mainline at least. I > > currently count 9 SoCs, added since 2010, which makes about 2-3 SoCs per > > year. > > So this is actually a slower rate that I've faced in my previous life > working for a silicon vendor ;-) And my experience is that the IPs were > different between the SoCs indeed but: > > 1. Not all of them at the same time (so no extra compatible values for > others). No, that's exactly the problem. We absolutely do not want to write compatible="vendor,soc-v1"; in a .dts file for SoC v2 just because we currently think, that we don't have to distinguish between those SoC versions in this specific driver. I think we all know it quite well, that there are (practically) always differences - sometimes documented, sometimes undocumented. And if you later find out, that you do have to differentiate in the driver - it's too late. Even if we disregard the argument of ugliness of having to set compatibility with soc-v1, soc-v2, soc-v3 in different DT nodes on an SoC v4. Thanks Guennadi > 2. When there was a change it required change in a driver as well (so > adding a compatible value is not an issue). > 3. The changes were *completely* unpredictable (so even comprehensive > list of DT properties wouldn't help) > > To summarize, count this as another vote for using compatible rather > then "universal & future-proof" set of properties. Unless there is a > very good rationale for it (I'm sure such cases exist) > > Thanks! > > Pawel > > --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/