From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from service87.mimecast.com ([91.220.42.44]:40172 "EHLO service87.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752542Ab3G2NHT convert rfc822-to-8bit (ORCPT ); Mon, 29 Jul 2013 09:07:19 -0400 Message-ID: <1375103234.10990.8.camel@hornet> Subject: Re: [PATCH 1/2] mmc: add Device Tree properties for UHS modes From: Pawel Moll Date: Mon, 29 Jul 2013 14:07:14 +0100 In-Reply-To: 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=UTF-8 Content-Transfer-Encoding: 8BIT Sender: devicetree-owner@vger.kernel.org To: Guennadi Liakhovetski 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, 2013-07-29 at 13:05 +0100, Guennadi Liakhovetski wrote: > 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. First of all I think your example calls for more than one compatible string - if it seems that soc,v2 is almost like soc,v1, make it compatible = "soc-v2", "soc-v1" and don't touch the driver (as in: keep it compatible with "soc-v1" only). Then, when the realisation comes, you can simply add the "soc-v2" of_device_id with .data pointing at new features. Now the other thing - do you have a driver for a SoC at all? What I mean is that in most cases it's the components/peripherals/IPs (whatever you call them) matter, not the SoC itself, so the SoC compatible value can be unique if you wish (and, if it is a *.dtsi, it will be compatbile with "simple-bus" anyway ;-). Then the IP nodes can follow the rule above. Hope it makes some sense? Pawel