On Thu, Feb 20, 2014 at 09:03:30AM +0000, Olof Johansson wrote: > So, after giving this some more thought (and getting my hands dirty in > some of this code), I think I'm going to change my mind on this. For > mobile platforms I think it might make sense to bring over the > toplevel platform Kconfig from arch/arm, to simplify dependencies > without tearing up the driver subtree with churn like this. > > This, of course, only holds true for v8 mobile platforms. Samsung > isn't saying if GH7 is a server platform and not, and they don't have > to tell us. But I think we should consider only enabling and bringing > over the mobile ones (and ideally try to avoid even that, but it might > make sense to do some of them at least initially -- it does provide > some convenient ways to enable larger subsets of default drivers per > platform/vendor family). > > I.e. I'd be OK with an > ARCH_EXYNOS/ARCH_TEGRA/ARCH_IMX/ARCH_<whatever>, but I don't think we > should add more finegrained options than that globally on ARM64, at > least not until truly proven to be needed. We're trying to push back > against new per-SoC Kconfig entries on 32-bit as well right now. I'm fine with this. Do we still need something for ARMv8 server platforms like ARCH_ARM_SBSA? The only advantage would be to make it easier for mobile targeted kernel builds to disable server features but I'm not sure there are so many such features, people can trim the .config manually. Two additional points: 1. Single arm64 defconfig file covering everything 2. Modules rather than built-in by default where possible (especially for server platforms) -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |