Proposal: document where SoC info belongs

Hi,

To try to move things along, I'm picking a small piece out of my
previous discussion [1] to see if we can make some progress.

Right now, the top-level "compatible" string in a dts file usually
contains one or more strings to represent the SoC. Examples chosen
semi-randomly:

exynos5250-snow.dts:
- compatible: "google,snow-rev4", "google,snow", "samsung,exynos5250",
"samsung,exynos5"
- SoC: "samsung,exynos5250", "samsung,exynos5"

sun20i-d1-clockworkpi-v3.14.dts:
- compatible: "clockwork,r-01-clockworkpi-v3.14", "allwinner,sun20i-d1"
- SoC: "allwinner,sun20i-d1"

sdm845-db845c.dts:
- compatible: "thundercomm,db845c", "qcom,sdm845"
- SoC: "qcom,sdm845"

I propose that we DEPRECATE including SoC information in the top-level
compatible string and move it elsewhere. I propose these top-level
properties that should be used instead:

soc-family-compatible = "vendor,family";
soc-product-id = <0x1234>;
soc-product-variant = <0x1234>;
soc-product-description = "Something";
soc-major-rev = <0x1234>;
soc-minor-rev = <0x1234>;
soc-sub-rev = <0x1234>;

The family-compatible would be VERY high-level and is not intended to
be a marketing name. It would be something like "samsung,exynos",
"nvidia,tegra" or "google,google-silicon". The ONLY goal for this
string is that within a family, the other properties uniquely identify
a given SoC. This is a SINGLE string, NOT a list of strings. There is
no concept of being part of multiple families.

All the other numbers are hopefully self-explanatory. These values
could be absent (assumed 0) if they don't make sense for a given SoC.

The soc-product-description is designed to be some nice name that
represents the family, product-id, and product-variant but _not_ the
rev (since that's easy for anyone who cares to represent it as "rev
X.Y.Z")


The goals here are:
* Stop trying to jam so much into the top-level "compatible".
* Make it one step easier for bootloaders (or code packaging device
trees for bootloaders) to differentiate device trees / overlays. This
isn't _enough_ since this proposal doesn't include board info, but
it's a place to start.
* Make it easier to deal with "socketed" boards where the SoC can be replaced.

NOTE: if a set of devicetrees is provided to a bootloader, it could
not just look at these properties to help it pick a devicetree but it
could also change the properties to be more detailed (it could fill in
some of the minor/sub-revs, for instance).


I think this is a positive change for everyone and a cleaner way to
represent things even if you aren't dealing with the above problems.

What I'm looking for from people is some responses. Folks could choose:

A) Yes, this is great. We already have something like this and we'd
switch to your properties if it became a standard.

B) I like the idea, but I need an extra property to represent my SoC
and then I'd use it.

C) I like the idea and I'd use it, but with some changes.

D) We don't have anything like this today, but it sounds useful.

E) Why are you wasting my time? This isn't a useful problem. The SoC
belongs in the top-level compatible string, period.

F) Other (please specify)


FWIW, from chatting with Rob Herring offline, my understanding is:
* He doesn't think that using the "soc@0" is the right place for these
properties.
* He didn't seem enthusiastic about adding a new node and was more
amenable to adding properties, which is why I added a pile of
top-level properties.


[1] https://lore.kernel.org/r/CAD=FV=Ux7nGFnYEyX0cUL-9__BKnTYc+kAJjkF458ZnFS7zoJA@mail.gmail.com