On Thursday 20 February 2014 18:34:23 Tomasz Figa wrote: > On 20.02.2014 18:00, Arnd Bergmann wrote: > >> Of course nothing stops you from retaining more specific compatible > >> strings. In fact, this is probably the most appropriate solution, > >> because in future you might find out that certain SoCs need some special > >> differentiation, e.g. same ID value on two SoCs. > >> > >> So, to apply this to our case, our Exynos 5250 based Arndale board would > >> be changed from > >> > >> compatible = "insignal,arndale", "samsung,exynos5260"; > >> > >> to > >> > >> compatible = "insignal,arndale", "samsung,exynos5260", "samsung,exynos"; > > > > Right, this would make sense. > > > >> Now, the board file will be able to match simply by "samsung,exynos" > >> compatible string and SoC-specific code in mach-exynos (hopefully none > >> after it gets cleaned up fully) will use soc_is_exynos*() macros (what > >> AFAIK it is already doing at the moment). > > > > On principle, I would not take things out of the match list, if that > > would break booting with old DT file that don't list "samsung,exynos" > > as compatible. But for new SoCs that would work. > > My proposal was about simply adding a fully generic string, without > removing the specific ones. For already supported SoCs this is pretty > obvious, as existing DTBs would not have this generic string listed. But > the specific strings should be also present in DTSes of new SoCs, even > if not recognized by the kernel, to make sure that in future any > SoC-specific quirks could be easily handled. Yes, that's ideal. > > Using soc_is_exynos*() too much of course also isn't good. A lot of > > the things tested for should probably be checked from individual DT > > properties, but again we have to find the right balance. I wouldn't > > mind getting rid of the soc_is_exynos*() macros completely, because > > a) we can't use them in device drivers > > b) all platform code is supposed to be in drivers > > c) both rules are enforced for arm64 > > I fully agree. As I said, after cleaning up mach-exynos/ there should be > no more code left using soc_is_*() macros. Ideally, the whole > mach-exynos/ should collapse into a single, trivial file, with > everything done in dedicated drivers. Right. Arnd -- 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
