Hello, On Wed, 18 Jan 2017 16:20:10 -0600, Rob Herring wrote: > > > Rob, Mark, any opinion? > > > > Sigh, is how to do compatibles really not yet understood? Well, it seems like not everyone necessarily understands what is the best strategy to adopt (me included). > > I agree that a clarification would be good. There are really two > > options: > > > > 1. Have two compatible strings in the DT, the one that matches the > > exact SoC where the IP is found (first compatible string) and the > > one that matches some other SoC where the same IP is found (second > > compatible string). Originally, Linux only supports the second > > compatible string in its device driver, but if it happens that a > > difference is found between two IPs that we thought were the same, > > we can add support for the first compatible string in the driver, > > with a slightly different behavior. > > This. And no wildcards in the compatible string. OK. So it means that today we do something like: compatible = "baz,foo-12", "baz,foo-00"; and support only baz,foo-00 in the driver. If tomorrow we discover that there is in fact a difference between the two IP blocks, we can add support for baz,foo-12 in the driver, and handle the differences. But then, the DT still contains: compatible = "baz,foo-12", "baz,foo-00"; and therefore pretends that the IP block is compatible with "baz,foo-00" which is in fact *not* the case. It was a mistake to consider it as compatible. So we keep living with a DT that has incorrect information. > > > 2. Have a single compatible string in the DT, matching the exact SoC > > where the IP is found. This involves adding immediately this > > compatible string in the corresponding driver. > > I wouldn't object to this from a DT perspective as I have no clue > generally if IP blocks are "the same" or not. Subsystem maintainers will > object though. Knowing if IP blocks are "the same" is in fact not necessarily trivial. What appears to be identical IP blocks today might be discovered later as actually having subtle differences (sometimes not even visible in the datasheet). > > I've not really been able to figure out which of the two options is the > > most future-proof/appropriate. > > They are both future-proof. #2 has the disadvantage of requiring a > kernel update for a new SoC. Which is generally anyway needed because a new SoC will almost always require some new drivers, adjusting pin-muxing or clock drivers, etc. Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
