[PATCH 1/1] ARM: Exynos: Add generic compatible string

[arnd@arndb.de (Arnd Bergmann)]

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