On Mon, Feb 6, 2017 at 4:21 PM, Jayachandran C <jnair@xxxxxxxxxxxxxxxxxx> wrote: > On Mon, Feb 06, 2017 at 02:44:13PM +0100, Arnd Bergmann wrote: >> On Mon, Feb 6, 2017 at 11:06 AM, Will Deacon <will.deacon@xxxxxxx> wrote: > > The Vulcan architecture has been discontinued by Broadcom, so the platform > and device tree files should go away soon. Renames are going to be messy, it > will be better to keep Vulcan around until the transition is complete, and > then delete it. What are the disadvantages of a rename in your opinion? Are you mainly worried about merge conflicts or something else? >> Hmm, an alternative would be to add the new .dtsi file and start out with an >> #include of the existing file, with overrides for anything that needs changing. >> Similarly, the Kconfig symbol could just 'select ARCH_VULCAN' for now. > > Even in this case, we will need to copy the files from boot/dts/broadcom to > boot/dts/cavium along the way. The current patchset is (in my opinion) the > least messy way to accomplish the transition. But it is the maintainer's call, > so if you think it has to be done differently, I can update the patchset and > post again. I don't see the need to copy if we can do an #include and later move the file into the new place. I also see only three references to ARCH_VULCAN at all aside from the dts file. arch/arm64/configs/defconfig:CONFIG_ARCH_VULCAN=y drivers/gpio/Kconfig: depends on OF_GPIO && (CPU_XLP || ARCH_VULCAN || COMPILE_TEST) drivers/i2c/busses/Kconfig: depends on CPU_XLP || ARCH_VULCAN || COMPILE_TEST drivers/spi/Kconfig: depends on CPU_XLP || ARCH_VULCAN || COMPILE_TEST We can probably manage to have a single patch to rename them all at the same time, or we do the add+remove over two merge windows. I also noticed now that you dropped the vulcan "compatible" strings in the .dtsi files, I think we should keep those as a fallback, and to avoid having interdependencies with the driver updates, e.g. the top-level compatible string should be compatible = "cavium,thunder-9900", "brcm,vulcan-soc"; for the SoC, plus of course the board specific identifier in front of that. Same for the CPU, the i2c, gpio, and pmu. 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