Re: Moving ARM dts files

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Dec 5, 2018 at 2:20 AM Linus Walleij <linus.walleij@xxxxxxxxxx> wrote:
>
> On Wed, Dec 5, 2018 at 7:02 AM Jisheng Zhang
> <Jisheng.Zhang@xxxxxxxxxxxxx> wrote:
> > Rob Herring <robh@xxxxxxxxxx> wrote:
>
> > >     'armada' : 'marvell',
> > >     'berlin' : 'marvell',
> >
> > Now, berlin SoC is synaptics' SoC ;)

But we're not changing the names of existing SoCs and at least so far
there aren't new 32-bit berlin SoCs.

> This illustrates perfectly the artificial nature of using vendor names
> as prefixes with DT properties, prefix names, directories etc.
>
> Companies start out purporting to be some eternal entity and the
> next day they buy each other left and right and license their
> hardware IP to whoever wants it.
>
> 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.

Uh, no. i.MX23 is a Sigmatel chip STMP?? which shared absolutely
nothing with other i.MX chips except for the derivatives that
followed. IIRC, STMP chips were even partially upstream.

Marketing names change at the whim of marketing and don't even require
a sale of a company.

> omap/* containing all OMAP platforms, msm/* for all Qualcomm
> SoCs etc. SoC names/codenames are at least eternal once they
> have been manufactured and we can keep them together
> no matter what vendor currently controls it.

Where do TI amXXXX chips go? Not all QC chips are 'msm' and I think
that name is abandoned now. No solution is going to be perfect.

We are already use vendors for arm64 (except for the oddball exynos),
so if we change arm, we shouldn't do something different. EBBR is also
going with vendor for firmware directories in the EFI system
partition. Speak up if you want to change that before 1.0.

> However I think there was a fork in the road ages ago when
> someone or something decided to use vendor prefixes for
> DT properties leading to this situation that we can no longer
> back out of.

It was simpler times...

> It has the side effect of splitting DTS files with the same SoC
> in two different folders marvell/* and synaptics/*
> it's a bit meh.

All I really care about here is things are organized by maintainers.
Someone care to write a script to ensure all 1800 files have a
maintainer attached to them (that is not me)?

Rob



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux