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 -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html