On Wed, Dec 5, 2018 at 9:34 AM Jisheng Zhang <Jisheng.Zhang@xxxxxxxxxxxxx> wrote: > [Me] > > It actually makes much more sense to organize these files by > > the SoC family name, because that doesn't change when the > > SoC is sold to another company. > > If the SoC is sold to another company, then > > case1: The original SoC family is renamed to another family. > > case2: Based on the original SoC, a newer SoC family comes out. > > I'm not sure it's still fine to put the new or renamed SoCs' files into the > original SoC directory. > > Another issue is: who will be the maintainer of new or renamed SoC family? Of course marketing prefer to associate the acquired company's SoC with itself and rename it. But that doesn't account for the case where the same SoC is produced by the new owner under the old name. Example: The Gemini SoC arch/arm/boot/dts/gemini-* https://dflund.se/~triad/krad/gemini/ This SoC was produced by StorLink Semiconductor in Taiwan early 2000s. At some point between 2000 and 2008 the company changed its name and/or got restructured and was renamed Storm Semiconductor. The masks for the packaging was retained so the chips still said "StorLink". Then in 2008 Cortina Systems acquired Storm Semiconductor eventually changed the masks and and renamed the identical chips from "SLnnnn" to "CSnnnn" but the chip inside the package was still the same. The SoC is still codenamed "Gemini", that is the only constant. And now we will put these devicetrees into folder...? storlink/ storm/ cortina/ If we look at the chip packageing, it should be different folders depending on what supplier was used when the device was manufactured. This is why the Vendor scheme is not really working. Another issue is illustrated again with the Synaptics device: an SoC produced exclusively for Synaptics (IIUC) but with a intimate relationship to a very easily identifed SoC. This naming nomenclature is a half-measure and a can of worms, that is my only point. Yours, Linus Walleij
