This is a bit of nitpicking that occurred to me while studying the output from LK.
Why is there no definition for qcom,msm-id in ./Documentation/devicetree/bindings
and no entry in ./arch/arm64/boot/dts/qcom/msm8996.dtsi when there are entries in:
./arch/arm64/boot/dts/qcom/msm8998.dtsi: qcom,msm-id = <292 0x0>;
./arch/arm64/boot/dts/qcom/msm8994.dtsi: qcom,msm-id = <207 0x20000>;
./arch/arm64/boot/dts/qcom/msm8992.dtsi: qcom,msm-id = <251 0>, <252 0>;AFAIR, this property is only used by LK (not Linux) to determine which device-tree blob to use when a device-tree table is part of the bootimg. This allows to have a same boot-image (mainly kernel+devicetreeS) for several boards, LK cherry picking the device-tree matching the hardware ID. The device-tree table format is however non-standard and needs to be generated with a vendor tool (skales). 96Boards/Linaro releases do not use this mechanism and we generate standard boot-images with a single device-tree blob (a boot-image per board), so LK does not have choice and is forced to use the unique available device-tree: dev_tree.c « msm_shared « platform - working/qualcomm/lk.git - [no description]
Thanks Loic. I remember watching a conference video of a Device Tree meeting where they were considering the fact that a number of projects are now using Device Tree and there needed to be some coordination of the bindings documentation to prevent fragmentation and conflicts. I cannot remember if there was a conclusion or where the central repository should be but I would think kernel.org would be the obvious place.
If anyone else took an interest in this thread, take a look at this:
SAN19-109 - Device Tree Evolution Project
