On 20 February 2014 23:18, Arnd Bergmann <arnd@xxxxxxxx> wrote: > 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. Now that we have a broader agreement on this, I think we can go ahead with the following steps as an initial approach: 1. Have a common machine file for both exynos4 and 5 files, mach-exynos-dt.c. 2. Introduce a generic compatible string "samsung,exynos". 3. Append this to the compatible property list for existing boards. If this plan looks OK, I can send across patches doing this. -- With warm regards, Sachin -- 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
