On Tuesday 25 February 2014, Olof Johansson wrote: > I disagree. I don't know what Samsung has in mind, but the revision of > the CPU doesn't have all that much to do with the rest of the SoC. > It's quite likely that some vendors (maybe not Samsung, but the same > concept applies) will ship 64-bit SoCs that are very similar to their > preceding 32-bit ones, same IP, similar busses, etc. I'm pretty sure > at least some vendors will do very close to that. Right. > So, if EXYNOS4 and EXYNOS5 can share a compatible value when they use > different CPUs, then there's no reason that whatever future 64-bit > ones can also share it. How about putting both 'samsung,exynos' and 'samsung,exynos4' in DT then and having the platform code match exynos4 and exynos5 but not exynos? That way, I think we are consistent and future-proof. Any code that needs to know if it's running on some exynos version can just check for the 'samsung,exynos' compatible value and that will work on both arm32 and arm64. Also, if we ever decide we want to run a 32-bit kernel on a 64-bit exynos, we can just add 'samsung,exynos6' (or whatever number that will be) to the list. My usual disclaimer for this: You should never ever consider actually running a 32-bit kernel on a 64-bit CPU, but at the same time there shouldn't be any reason why it won't work either, given that we require arm64 based systems to have all SoC specific code in drivers and we can use the same drivers on arm32. 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
