On Mon, Nov 17, 2014 at 1:16 PM, Arnd Bergmann <arnd@xxxxxxxx> wrote: > I still think this is different in the sense that ARM multiplatform > support is about combining platforms from separate mach-* directories, > while your approach was to rewrite multiple mach-* directories into > a single new one that remains separate from the others. While this is > a great improvement, it doesn't get you any closer to having a > combined BMIPS+RALINK+JZ4740+ATH79 kernel for instance. I don't know > if such a kernel is something that anybody wants, or if it's even > technically possible. > > If you wanted to do that however, starting with BMIPS you'd have > to make it possible to define a new platform without the > arch/mips/include/asm/mach-bmips/ directory (this should be possible > already, so the hardest part is done), replace all global function > calls (arch_init_irq, prom_init, get_system_type, ...) with generic > platform-independent implementations or wrappers around per-platform > callbacks, and move the Kconfig section for CONFIG_BMIPS_MULTIPLATFORM > outside of the "System type" choice statement. > Until you do that, your platform isn't "more multipliplatform" than > the others really, it just abstracts the differences between some > SoCs nicer than most. I guess a big blocker for such a real mips multiplatform kernel is that there is still no defined (standard) interface for passing a device tree to the kernel from the bootlader on mips, unlike on arm (at least I'm not aware of any). And unless there is one, having a multiplatform kernel does not make much sense, as there is no sane way to tell apart different platforms on boot. But maybe we should just define a way, and require new platforms to use it ;-) Jonas -- 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
