[PATCH 0/4] dt-bindings: arm: qcom: qcom,board-id and qcom,msm-id

[PATCH 0/4] dt-bindings: arm: qcom: qcom,board-id and qcom,msm-id

[Krzysztof Kozlowski]

Hi,

The discussion [1] brought several arguments for keeping the qcom,board-id and
qcom,msm-id properties.  Keeping means we should document them, so the DT
schema checks pass.

I revived old patch [2] with several changes and improvements.  The commit msg
hopefully collects feedback from the discussion.

Best regards,
Krzysztof

[1] https://lore.kernel.org/r/a3c932d1-a102-ce18-deea-18cbbd05ecab@linaro.org/
[2] https://lore.kernel.org/all/1425503602-24916-1-git-send-email-galak@codeaurora.org/

Krzysztof Kozlowski (4):
  dt-bindings: arm: qcom: document qcom,msm-id and qcom,board-id
  arm64: dts: qcom: msm8992-xiaomi-libra: split qcom,msm-id into tuples
  arm64: dts: qcom: msm8998-oneplus: split qcom,board-id into tuples
  arm64: dts: qcom: sdm845-oneplus: split qcom,board-id into tuples

 .../devicetree/bindings/arm/qcom.yaml         | 58 +++++++++++++++++++
 .../boot/dts/qcom/msm8992-xiaomi-libra.dts    |  2 +-
 .../dts/qcom/msm8998-oneplus-cheeseburger.dts |  2 +-
 .../dts/qcom/msm8998-oneplus-dumpling.dts     |  2 +-
 .../dts/qcom/sdm845-oneplus-enchilada.dts     |  2 +-
 .../boot/dts/qcom/sdm845-oneplus-fajita.dts   |  2 +-
 include/dt-bindings/arm/qcom,ids.h            | 30 ++++++++++
 7 files changed, 93 insertions(+), 5 deletions(-)
 create mode 100644 include/dt-bindings/arm/qcom,ids.h

-- 
2.34.1

[PATCH 1/4] dt-bindings: arm: qcom: document qcom,msm-id and qcom,board-id

[Krzysztof Kozlowski]

The top level qcom,msm-id and qcom,board-id properties are utilized by
bootloaders on Qualcomm MSM platforms to determine which device tree
should be used and passed to the kernel.

The commit b32e592d3c28 ("devicetree: bindings: Document qcom board
compatible format") from 2015 was a consensus during discussion about
upstreaming qcom,msm-id and qcom,board-id fields.  There are however still
problems with that consensus:
1. It was reached 7 years ago but it turned out its implementation did
   not reach all possible products.

2. Initially additional tool (dtbTool) was needed for parsing these
   fields to create a QCDT image consisting of multiple DTBs, later the
   bootloaders were improved and they use these qcom,msm-id and
   qcom,board-id properties directly.

3. Extracting relevant information from the board compatible requires
   this additional tool (dtbTool), which makes the build process more
   complicated and not easily reproducible (DTBs are modified after the
   kernel build).

4. Some versions of Qualcomm bootloaders expect these properties even
   when booting with a single DTB.  The community is stuck with these
   bootloaders thus they require properties in the DTBs.

Since several upstreamed Qualcomm SoC-based boards require these
properties to properly boot and the properties are reportedly used by
bootloaders, document them.

Link: https://lore.kernel.org/r/a3c932d1-a102-ce18-deea-18cbbd05ecab@linaro.org/
Co-developed-by: Kumar Gala <galak@codeaurora.org>
Signed-off-by: Kumar Gala <galak@codeaurora.org>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
 .../devicetree/bindings/arm/qcom.yaml         | 58 +++++++++++++++++++
 include/dt-bindings/arm/qcom,ids.h            | 30 ++++++++++
 2 files changed, 88 insertions(+)
 create mode 100644 include/dt-bindings/arm/qcom,ids.h

diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
index 6c38c1387afd..b7fa85c1e478 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -403,6 +403,64 @@ properties:
               - qcom,sm8450-qrd
           - const: qcom,sm8450
 
+  # Board compatibles go above
+
+  qcom,msm-id:
+    $ref: /schemas/types.yaml#/definitions/uint32-matrix
+    minItems: 1
+    maxItems: 8
+    items:
+      items:
+        - description: |
+            MSM chipset ID - an exact match value consisting of three bitfields::
+             - bits 0-15  - The unique MSM chipset ID
+             - bits 16-31 - Reserved; should be 0
+        - description: |
+            Hardware revision ID - a chipset specific 32-bit ID representing
+            the version of the chipset.  It is best a match value - the
+            bootloader will look for the closest possible match.
+    description:
+      The MSM chipset and hardware revision use by Qualcomm bootloaders.  It
+      can optionally be an array of these to indicate multiple hardware that
+      use the same device tree.  It is expected that the bootloader will use
+      this information at boot-up to decide which device tree to use when given
+      multiple device trees, some of which may not be compatible with the
+      actual hardware.  It is the bootloader's responsibility to pass the
+      correct device tree to the kernel.
+      This is a legacy property - it is not expected on newer boards (starting
+      with SM8350).
+
+  qcom,board-id:
+    $ref: /schemas/types.yaml#/definitions/uint32-matrix
+    minItems: 1
+    maxItems: 8
+    items:
+      items:
+        - description: |
+            Board ID consisting of three bitfields::
+              - bits 31-24 - Unusued
+              - bits 23-16 - Platform Version Major
+              - bits 15-8  - Platform Version Minor
+              - bits 7-0   - Platform Type
+            Platform Type field is an exact match value.  The
+            Platform Major/Minor field is a best match.  The bootloader will
+            look for the closest possible match.
+        - description: |
+            Subtype ID unique to a Platform Type/Chipset ID.  For a given
+            Platform Type, there will typically only be a single board and the
+            subtype_id will be 0.  However in some cases board variants may
+            need to be distinguished by different subtype_id values.
+    description:
+      The board type and revision information.  It can optionally be an array
+      of these to indicate multiple boards that use the same device tree.  It
+      is expected that the bootloader will use this information at boot-up to
+      decide which device tree to use when given multiple device trees, some of
+      which may not be compatible with the actual hardware.  It is the
+      bootloader's responsibility to pass the correct device tree to the
+      kernel
+      This is a legacy property - it is not expected on newer boards (starting
+      with SM8350).
+
 additionalProperties: true
 
 ...
diff --git a/include/dt-bindings/arm/qcom,ids.h b/include/dt-bindings/arm/qcom,ids.h
new file mode 100644
index 000000000000..eaf86c18650f
--- /dev/null
+++ b/include/dt-bindings/arm/qcom,ids.h
@@ -0,0 +1,30 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2022 Linaro Ltd
+ * Author: Krzysztof Kozlowski <krzk@kernel.org> based on previous work of Kumar Gala.
+ */
+#ifndef _DT_BINDINGS_ARM_QCOM_IDS_H
+#define _DT_BINDINGS_ARM_QCOM_IDS_H
+
+/* qcom,msm-id */
+#define QCOM_ID_APQ8026				199
+#define QCOM_ID_MSM8916				206
+#define QCOM_ID_MSM8994				207
+#define QCOM_ID_MSM8996_3_0			246
+#define QCOM_ID_APQ8016				247
+#define QCOM_ID_MSM8216				248
+#define QCOM_ID_MSM8116				249
+#define QCOM_ID_MSM8616				250
+#define QCOM_ID_MSM8998				292
+#define QCOM_ID_SDM845				321
+
+/* qcom,board-id */
+#define QCOM_BOARD_ID(a, major, minor) \
+	(((major & 0xff) << 16) | ((minor & 0xff) << 8) | QCOM_BOARD_ID_##a)
+
+#define QCOM_BOARD_ID_MTP			8
+#define QCOM_BOARD_ID_DRAGONBOARD		10
+#define QCOM_BOARD_ID_SBC			24
+
+#endif /* _DT_BINDINGS_ARM_QCOM_IDS_H */
-- 
2.34.1

Re: [PATCH 1/4] dt-bindings: arm: qcom: document qcom,msm-id and qcom,board-id

[Rob Herring]

On Sun, May 29, 2022 at 10:26:26PM +0200, Krzysztof Kozlowski wrote:
> The top level qcom,msm-id and qcom,board-id properties are utilized by
> bootloaders on Qualcomm MSM platforms to determine which device tree
> should be used and passed to the kernel.
> 
> The commit b32e592d3c28 ("devicetree: bindings: Document qcom board
> compatible format") from 2015 was a consensus during discussion about
> upstreaming qcom,msm-id and qcom,board-id fields.  There are however still
> problems with that consensus:
> 1. It was reached 7 years ago but it turned out its implementation did
>    not reach all possible products.
> 
> 2. Initially additional tool (dtbTool) was needed for parsing these
>    fields to create a QCDT image consisting of multiple DTBs, later the
>    bootloaders were improved and they use these qcom,msm-id and
>    qcom,board-id properties directly.
> 
> 3. Extracting relevant information from the board compatible requires
>    this additional tool (dtbTool), which makes the build process more
>    complicated and not easily reproducible (DTBs are modified after the
>    kernel build).
> 
> 4. Some versions of Qualcomm bootloaders expect these properties even
>    when booting with a single DTB.  The community is stuck with these
>    bootloaders thus they require properties in the DTBs.
> 
> Since several upstreamed Qualcomm SoC-based boards require these
> properties to properly boot and the properties are reportedly used by
> bootloaders, document them.

My primary issue here is accepting this will be an endorsement for 
other vendors doing something similar. I'm not against an ID 
property(ies) in the root node, but would rather see something common 
if we do anything.

Rob

Re: [PATCH 1/4] dt-bindings: arm: qcom: document qcom,msm-id and qcom,board-id

[Krzysztof Kozlowski]

On 05/06/2022 17:07, Rob Herring wrote:
> On Sun, May 29, 2022 at 10:26:26PM +0200, Krzysztof Kozlowski wrote:
>> The top level qcom,msm-id and qcom,board-id properties are utilized by
>> bootloaders on Qualcomm MSM platforms to determine which device tree
>> should be used and passed to the kernel.
>>
>> The commit b32e592d3c28 ("devicetree: bindings: Document qcom board
>> compatible format") from 2015 was a consensus during discussion about
>> upstreaming qcom,msm-id and qcom,board-id fields.  There are however still
>> problems with that consensus:
>> 1. It was reached 7 years ago but it turned out its implementation did
>>    not reach all possible products.
>>
>> 2. Initially additional tool (dtbTool) was needed for parsing these
>>    fields to create a QCDT image consisting of multiple DTBs, later the
>>    bootloaders were improved and they use these qcom,msm-id and
>>    qcom,board-id properties directly.
>>
>> 3. Extracting relevant information from the board compatible requires
>>    this additional tool (dtbTool), which makes the build process more
>>    complicated and not easily reproducible (DTBs are modified after the
>>    kernel build).
>>
>> 4. Some versions of Qualcomm bootloaders expect these properties even
>>    when booting with a single DTB.  The community is stuck with these
>>    bootloaders thus they require properties in the DTBs.
>>
>> Since several upstreamed Qualcomm SoC-based boards require these
>> properties to properly boot and the properties are reportedly used by
>> bootloaders, document them.
> 
> My primary issue here is accepting this will be an endorsement for 
> other vendors doing something similar. I'm not against an ID 
> property(ies) in the root node, but would rather see something common 
> if we do anything.

Hi Rob,

A more common approach was merged back in 2015 - encoding this ID
information in the board compatibles. If I understood previous
discussion correctly, this common method was later used by Qualcomm DTB
post-processing tool. At least for some of the cases.

Other cases (several Qualcomm boards from different vendors) still use
these ID properties. It even turns out they use it differently between
vendors (e.g. Xiaomi vs OnePlus).

Important arguments for documenting these properties:
1. These ID properties are already on released boards where changing
bootloader is non-trivial or even not possible. It will not be possible
to remove these properties, without seriously affecting the community
working with them.

2. According to Konrad [1] (second paragraph), newer chipsets (starting
with sm8350 released in 2021) do not use these properties. These newer
DTS do not have them.

Considering 1+2 above, maybe let's document these properties as
compatible? Would that solve your point of "endorsement for other vendors"?

[1]
https://lore.kernel.org/all/20220522195138.35943-1-konrad.dybcio@somainline.org/


Best regards,
Krzysztof

Re: [PATCH 1/4] dt-bindings: arm: qcom: document qcom,msm-id and qcom,board-id

[Rob Herring]

On Tue, Jun 07, 2022 at 01:15:51PM +0200, Krzysztof Kozlowski wrote:
> On 05/06/2022 17:07, Rob Herring wrote:
> > On Sun, May 29, 2022 at 10:26:26PM +0200, Krzysztof Kozlowski wrote:
> >> The top level qcom,msm-id and qcom,board-id properties are utilized by
> >> bootloaders on Qualcomm MSM platforms to determine which device tree
> >> should be used and passed to the kernel.
> >>
> >> The commit b32e592d3c28 ("devicetree: bindings: Document qcom board
> >> compatible format") from 2015 was a consensus during discussion about
> >> upstreaming qcom,msm-id and qcom,board-id fields.  There are however still
> >> problems with that consensus:
> >> 1. It was reached 7 years ago but it turned out its implementation did
> >>    not reach all possible products.
> >>
> >> 2. Initially additional tool (dtbTool) was needed for parsing these
> >>    fields to create a QCDT image consisting of multiple DTBs, later the
> >>    bootloaders were improved and they use these qcom,msm-id and
> >>    qcom,board-id properties directly.
> >>
> >> 3. Extracting relevant information from the board compatible requires
> >>    this additional tool (dtbTool), which makes the build process more
> >>    complicated and not easily reproducible (DTBs are modified after the
> >>    kernel build).
> >>
> >> 4. Some versions of Qualcomm bootloaders expect these properties even
> >>    when booting with a single DTB.  The community is stuck with these
> >>    bootloaders thus they require properties in the DTBs.
> >>
> >> Since several upstreamed Qualcomm SoC-based boards require these
> >> properties to properly boot and the properties are reportedly used by
> >> bootloaders, document them.
> > 
> > My primary issue here is accepting this will be an endorsement for 
> > other vendors doing something similar. I'm not against an ID 
> > property(ies) in the root node, but would rather see something common 
> > if we do anything.
> 
> Hi Rob,
> 
> A more common approach was merged back in 2015 - encoding this ID
> information in the board compatibles. If I understood previous
> discussion correctly, this common method was later used by Qualcomm DTB
> post-processing tool. At least for some of the cases.
> 
> Other cases (several Qualcomm boards from different vendors) still use
> these ID properties. It even turns out they use it differently between
> vendors (e.g. Xiaomi vs OnePlus).
> 
> Important arguments for documenting these properties:
> 1. These ID properties are already on released boards where changing
> bootloader is non-trivial or even not possible. It will not be possible
> to remove these properties, without seriously affecting the community
> working with them.

Accepting things because they are already in use is also not a path we 
want to go down. If it's the color of the bike shed, then fine.

> 2. According to Konrad [1] (second paragraph), newer chipsets (starting
> with sm8350 released in 2021) do not use these properties. These newer
> DTS do not have them.
> 
> Considering 1+2 above, maybe let's document these properties as
> compatible? Would that solve your point of "endorsement for other vendors"?

What do you mean? Only allow them for certain root compatible strings? I 
suppose that would be okay by me. It would also be useful documentation 
of where they are needed.

Rob

Re: [PATCH 1/4] dt-bindings: arm: qcom: document qcom,msm-id and qcom,board-id

[Krzysztof Kozlowski]

On 10/06/2022 18:33, Rob Herring wrote:
> On Tue, Jun 07, 2022 at 01:15:51PM +0200, Krzysztof Kozlowski wrote:
>> On 05/06/2022 17:07, Rob Herring wrote:
>>> On Sun, May 29, 2022 at 10:26:26PM +0200, Krzysztof Kozlowski wrote:
>>>> The top level qcom,msm-id and qcom,board-id properties are utilized by
>>>> bootloaders on Qualcomm MSM platforms to determine which device tree
>>>> should be used and passed to the kernel.
>>>>
>>>> The commit b32e592d3c28 ("devicetree: bindings: Document qcom board
>>>> compatible format") from 2015 was a consensus during discussion about
>>>> upstreaming qcom,msm-id and qcom,board-id fields.  There are however still
>>>> problems with that consensus:
>>>> 1. It was reached 7 years ago but it turned out its implementation did
>>>>    not reach all possible products.
>>>>
>>>> 2. Initially additional tool (dtbTool) was needed for parsing these
>>>>    fields to create a QCDT image consisting of multiple DTBs, later the
>>>>    bootloaders were improved and they use these qcom,msm-id and
>>>>    qcom,board-id properties directly.
>>>>
>>>> 3. Extracting relevant information from the board compatible requires
>>>>    this additional tool (dtbTool), which makes the build process more
>>>>    complicated and not easily reproducible (DTBs are modified after the
>>>>    kernel build).
>>>>
>>>> 4. Some versions of Qualcomm bootloaders expect these properties even
>>>>    when booting with a single DTB.  The community is stuck with these
>>>>    bootloaders thus they require properties in the DTBs.
>>>>
>>>> Since several upstreamed Qualcomm SoC-based boards require these
>>>> properties to properly boot and the properties are reportedly used by
>>>> bootloaders, document them.
>>>
>>> My primary issue here is accepting this will be an endorsement for 
>>> other vendors doing something similar. I'm not against an ID 
>>> property(ies) in the root node, but would rather see something common 
>>> if we do anything.
>>
>> Hi Rob,
>>
>> A more common approach was merged back in 2015 - encoding this ID
>> information in the board compatibles. If I understood previous
>> discussion correctly, this common method was later used by Qualcomm DTB
>> post-processing tool. At least for some of the cases.
>>
>> Other cases (several Qualcomm boards from different vendors) still use
>> these ID properties. It even turns out they use it differently between
>> vendors (e.g. Xiaomi vs OnePlus).
>>
>> Important arguments for documenting these properties:
>> 1. These ID properties are already on released boards where changing
>> bootloader is non-trivial or even not possible. It will not be possible
>> to remove these properties, without seriously affecting the community
>> working with them.
> 
> Accepting things because they are already in use is also not a path we 
> want to go down. If it's the color of the bike shed, then fine.
> 
>> 2. According to Konrad [1] (second paragraph), newer chipsets (starting
>> with sm8350 released in 2021) do not use these properties. These newer
>> DTS do not have them.
>>
>> Considering 1+2 above, maybe let's document these properties as
>> compatible? Would that solve your point of "endorsement for other vendors"?
> 
> What do you mean? Only allow them for certain root compatible strings? I 
> suppose that would be okay by me. It would also be useful documentation 
> of where they are needed.

Bah, I wrote something else than I had in mind. So one more try:

Considering 1+2 above, maybe let's document these properties as
*deprecated*? Would that solve your point of "endorsement for other
vendors"?

However the idea to restrict them per-compatible, is also nice. Although
I cannot guarantee the list will not grow for older SoCs.


Best regards,
Krzysztof

Re: [PATCH 1/4] dt-bindings: arm: qcom: document qcom,msm-id and qcom,board-id

[Rob Herring]

On Sat, Jun 11, 2022 at 7:07 AM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> On 10/06/2022 18:33, Rob Herring wrote:
> > On Tue, Jun 07, 2022 at 01:15:51PM +0200, Krzysztof Kozlowski wrote:
> >> On 05/06/2022 17:07, Rob Herring wrote:
> >>> On Sun, May 29, 2022 at 10:26:26PM +0200, Krzysztof Kozlowski wrote:
> >>>> The top level qcom,msm-id and qcom,board-id properties are utilized by
> >>>> bootloaders on Qualcomm MSM platforms to determine which device tree
> >>>> should be used and passed to the kernel.
> >>>>
> >>>> The commit b32e592d3c28 ("devicetree: bindings: Document qcom board
> >>>> compatible format") from 2015 was a consensus during discussion about
> >>>> upstreaming qcom,msm-id and qcom,board-id fields.  There are however still
> >>>> problems with that consensus:
> >>>> 1. It was reached 7 years ago but it turned out its implementation did
> >>>>    not reach all possible products.
> >>>>
> >>>> 2. Initially additional tool (dtbTool) was needed for parsing these
> >>>>    fields to create a QCDT image consisting of multiple DTBs, later the
> >>>>    bootloaders were improved and they use these qcom,msm-id and
> >>>>    qcom,board-id properties directly.
> >>>>
> >>>> 3. Extracting relevant information from the board compatible requires
> >>>>    this additional tool (dtbTool), which makes the build process more
> >>>>    complicated and not easily reproducible (DTBs are modified after the
> >>>>    kernel build).
> >>>>
> >>>> 4. Some versions of Qualcomm bootloaders expect these properties even
> >>>>    when booting with a single DTB.  The community is stuck with these
> >>>>    bootloaders thus they require properties in the DTBs.
> >>>>
> >>>> Since several upstreamed Qualcomm SoC-based boards require these
> >>>> properties to properly boot and the properties are reportedly used by
> >>>> bootloaders, document them.
> >>>
> >>> My primary issue here is accepting this will be an endorsement for
> >>> other vendors doing something similar. I'm not against an ID
> >>> property(ies) in the root node, but would rather see something common
> >>> if we do anything.
> >>
> >> Hi Rob,
> >>
> >> A more common approach was merged back in 2015 - encoding this ID
> >> information in the board compatibles. If I understood previous
> >> discussion correctly, this common method was later used by Qualcomm DTB
> >> post-processing tool. At least for some of the cases.
> >>
> >> Other cases (several Qualcomm boards from different vendors) still use
> >> these ID properties. It even turns out they use it differently between
> >> vendors (e.g. Xiaomi vs OnePlus).
> >>
> >> Important arguments for documenting these properties:
> >> 1. These ID properties are already on released boards where changing
> >> bootloader is non-trivial or even not possible. It will not be possible
> >> to remove these properties, without seriously affecting the community
> >> working with them.
> >
> > Accepting things because they are already in use is also not a path we
> > want to go down. If it's the color of the bike shed, then fine.
> >
> >> 2. According to Konrad [1] (second paragraph), newer chipsets (starting
> >> with sm8350 released in 2021) do not use these properties. These newer
> >> DTS do not have them.
> >>
> >> Considering 1+2 above, maybe let's document these properties as
> >> compatible? Would that solve your point of "endorsement for other vendors"?
> >
> > What do you mean? Only allow them for certain root compatible strings? I
> > suppose that would be okay by me. It would also be useful documentation
> > of where they are needed.
>
> Bah, I wrote something else than I had in mind. So one more try:
>
> Considering 1+2 above, maybe let's document these properties as
> *deprecated*? Would that solve your point of "endorsement for other
> vendors"?

Yes.

> However the idea to restrict them per-compatible, is also nice. Although
> I cannot guarantee the list will not grow for older SoCs.

No issue with that.

Rob

Re: [PATCH 1/4] dt-bindings: arm: qcom: document qcom,msm-id and qcom,board-id

[Dmitry Baryshkov]

On 13/06/2022 18:30, Rob Herring wrote:
> On Sat, Jun 11, 2022 at 7:07 AM Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org> wrote:
>>
>> On 10/06/2022 18:33, Rob Herring wrote:
>>> On Tue, Jun 07, 2022 at 01:15:51PM +0200, Krzysztof Kozlowski wrote:
>>>> On 05/06/2022 17:07, Rob Herring wrote:
>>>>> On Sun, May 29, 2022 at 10:26:26PM +0200, Krzysztof Kozlowski wrote:
>>>>>> The top level qcom,msm-id and qcom,board-id properties are utilized by
>>>>>> bootloaders on Qualcomm MSM platforms to determine which device tree
>>>>>> should be used and passed to the kernel.
>>>>>>
>>>>>> The commit b32e592d3c28 ("devicetree: bindings: Document qcom board
>>>>>> compatible format") from 2015 was a consensus during discussion about
>>>>>> upstreaming qcom,msm-id and qcom,board-id fields.  There are however still
>>>>>> problems with that consensus:
>>>>>> 1. It was reached 7 years ago but it turned out its implementation did
>>>>>>     not reach all possible products.
>>>>>>
>>>>>> 2. Initially additional tool (dtbTool) was needed for parsing these
>>>>>>     fields to create a QCDT image consisting of multiple DTBs, later the
>>>>>>     bootloaders were improved and they use these qcom,msm-id and
>>>>>>     qcom,board-id properties directly.
>>>>>>
>>>>>> 3. Extracting relevant information from the board compatible requires
>>>>>>     this additional tool (dtbTool), which makes the build process more
>>>>>>     complicated and not easily reproducible (DTBs are modified after the
>>>>>>     kernel build).
>>>>>>
>>>>>> 4. Some versions of Qualcomm bootloaders expect these properties even
>>>>>>     when booting with a single DTB.  The community is stuck with these
>>>>>>     bootloaders thus they require properties in the DTBs.
>>>>>>
>>>>>> Since several upstreamed Qualcomm SoC-based boards require these
>>>>>> properties to properly boot and the properties are reportedly used by
>>>>>> bootloaders, document them.
>>>>>
>>>>> My primary issue here is accepting this will be an endorsement for
>>>>> other vendors doing something similar. I'm not against an ID
>>>>> property(ies) in the root node, but would rather see something common
>>>>> if we do anything.
>>>>
>>>> Hi Rob,
>>>>
>>>> A more common approach was merged back in 2015 - encoding this ID
>>>> information in the board compatibles. If I understood previous
>>>> discussion correctly, this common method was later used by Qualcomm DTB
>>>> post-processing tool. At least for some of the cases.
>>>>
>>>> Other cases (several Qualcomm boards from different vendors) still use
>>>> these ID properties. It even turns out they use it differently between
>>>> vendors (e.g. Xiaomi vs OnePlus).
>>>>
>>>> Important arguments for documenting these properties:
>>>> 1. These ID properties are already on released boards where changing
>>>> bootloader is non-trivial or even not possible. It will not be possible
>>>> to remove these properties, without seriously affecting the community
>>>> working with them.
>>>
>>> Accepting things because they are already in use is also not a path we
>>> want to go down. If it's the color of the bike shed, then fine.
>>>
>>>> 2. According to Konrad [1] (second paragraph), newer chipsets (starting
>>>> with sm8350 released in 2021) do not use these properties. These newer
>>>> DTS do not have them.
>>>>
>>>> Considering 1+2 above, maybe let's document these properties as
>>>> compatible? Would that solve your point of "endorsement for other vendors"?
>>>
>>> What do you mean? Only allow them for certain root compatible strings? I
>>> suppose that would be okay by me. It would also be useful documentation
>>> of where they are needed.
>>
>> Bah, I wrote something else than I had in mind. So one more try:
>>
>> Considering 1+2 above, maybe let's document these properties as
>> *deprecated*? Would that solve your point of "endorsement for other
>> vendors"?
> 
> Yes.

It seems point 2 is not 100% correct. Qualcomm has been using these 
properties in the sm8350 and sm8450 dts files.

However to I'd suggest to continue with the agreement to mark these 
properties as deprecated (and compat-bound to Qualcomm devices/root 
compatible strings). Which means that adding them to the new DT file 
would require some justification. For example 'the board fails to boot 
without these properties' or 'we are demanded to provide a single boot 
image and using these properties allows bootloader to select the correct 
DTs.

> 
>> However the idea to restrict them per-compatible, is also nice. Although
>> I cannot guarantee the list will not grow for older SoCs.
> 
> No issue with that.
> 
> Rob


-- 
With best wishes
Dmitry

[PATCH 2/4] arm64: dts: qcom: msm8992-xiaomi-libra: split qcom,msm-id into tuples

[Krzysztof Kozlowski]

The qcom,msm-id is an uint32 matrix, so a list of tuples.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
 arch/arm64/boot/dts/qcom/msm8992-xiaomi-libra.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/msm8992-xiaomi-libra.dts b/arch/arm64/boot/dts/qcom/msm8992-xiaomi-libra.dts
index 7748b745a5df..15467b697e94 100644
--- a/arch/arm64/boot/dts/qcom/msm8992-xiaomi-libra.dts
+++ b/arch/arm64/boot/dts/qcom/msm8992-xiaomi-libra.dts
@@ -17,7 +17,7 @@ / {
 	chassis-type = "handset";
 
 	/* required for bootloader to select correct board */
-	qcom,msm-id = <251 0 252 0>;
+	qcom,msm-id = <251 0>, <252 0>;
 	qcom,pmic-id = <65545 65546 0 0>;
 	qcom,board-id = <12 0>;
 
-- 
2.34.1

[PATCH 3/4] arm64: dts: qcom: msm8998-oneplus: split qcom,board-id into tuples

[Krzysztof Kozlowski]

The qcom,board-id is an uint32 matrix, so a list of tuples.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
 arch/arm64/boot/dts/qcom/msm8998-oneplus-cheeseburger.dts | 2 +-
 arch/arm64/boot/dts/qcom/msm8998-oneplus-dumpling.dts     | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/msm8998-oneplus-cheeseburger.dts b/arch/arm64/boot/dts/qcom/msm8998-oneplus-cheeseburger.dts
index 9563eb62db88..0a6d3e4ac48f 100644
--- a/arch/arm64/boot/dts/qcom/msm8998-oneplus-cheeseburger.dts
+++ b/arch/arm64/boot/dts/qcom/msm8998-oneplus-cheeseburger.dts
@@ -13,7 +13,7 @@ / {
 	compatible = "oneplus,cheeseburger", "qcom,msm8998";
 	chassis-type = "handset";
 	/* Required for bootloader to select correct board */
-	qcom,board-id = <8 0 16859 23>;
+	qcom,board-id = <8 0>, <16859 23>;
 
 	/* Capacitive keypad button backlight */
 	leds {
diff --git a/arch/arm64/boot/dts/qcom/msm8998-oneplus-dumpling.dts b/arch/arm64/boot/dts/qcom/msm8998-oneplus-dumpling.dts
index 5d0dabbaee4e..60718c06e17e 100644
--- a/arch/arm64/boot/dts/qcom/msm8998-oneplus-dumpling.dts
+++ b/arch/arm64/boot/dts/qcom/msm8998-oneplus-dumpling.dts
@@ -12,7 +12,7 @@ / {
 	compatible = "oneplus,dumpling", "qcom,msm8998";
 	chassis-type = "handset";
 	/* Required for bootloader to select correct board */
-	qcom,board-id = <8 0 17801 43>;
+	qcom,board-id = <8 0>, <17801 43>;
 };
 
 /* Update the screen height values from 1920 to 2160 on the 5T */
-- 
2.34.1

[PATCH 4/4] arm64: dts: qcom: sdm845-oneplus: split qcom,board-id into tuples

[Krzysztof Kozlowski]

The qcom,board-id is an uint32 matrix, so a list of tuples.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
 arch/arm64/boot/dts/qcom/sdm845-oneplus-enchilada.dts | 2 +-
 arch/arm64/boot/dts/qcom/sdm845-oneplus-fajita.dts    | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/sdm845-oneplus-enchilada.dts b/arch/arm64/boot/dts/qcom/sdm845-oneplus-enchilada.dts
index bf2cf92e8976..8897a2f4cfe3 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-oneplus-enchilada.dts
+++ b/arch/arm64/boot/dts/qcom/sdm845-oneplus-enchilada.dts
@@ -12,7 +12,7 @@ / {
 	compatible = "oneplus,enchilada", "qcom,sdm845";
 	chassis-type = "handset";
 	qcom,msm-id = <0x141 0x20001>;
-	qcom,board-id = <8 0 17819 22>;
+	qcom,board-id = <8 0>, <17819 22>;
 
 	battery: battery {
 		compatible = "simple-battery";
diff --git a/arch/arm64/boot/dts/qcom/sdm845-oneplus-fajita.dts b/arch/arm64/boot/dts/qcom/sdm845-oneplus-fajita.dts
index 1b6b5bf368df..193cbd27b8b4 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-oneplus-fajita.dts
+++ b/arch/arm64/boot/dts/qcom/sdm845-oneplus-fajita.dts
@@ -12,7 +12,7 @@ / {
 	compatible = "oneplus,fajita", "qcom,sdm845";
 	chassis-type = "handset";
 	qcom,msm-id = <0x141 0x20001>;
-	qcom,board-id = <8 0 18801 41>;
+	qcom,board-id = <8 0>, <18801 41>;
 
 	battery: battery {
 		compatible = "simple-battery";
-- 
2.34.1

Re: [PATCH 4/4] arm64: dts: qcom: sdm845-oneplus: split qcom,board-id into tuples

[Stephan Gerhold]

+Cc Caleb Connolly <caleb@connolly.tech>

On Sun, May 29, 2022 at 10:26:29PM +0200, Krzysztof Kozlowski wrote:
> The qcom,board-id is an uint32 matrix, so a list of tuples.
> 
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> ---
>  arch/arm64/boot/dts/qcom/sdm845-oneplus-enchilada.dts | 2 +-
>  arch/arm64/boot/dts/qcom/sdm845-oneplus-fajita.dts    | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/qcom/sdm845-oneplus-enchilada.dts b/arch/arm64/boot/dts/qcom/sdm845-oneplus-enchilada.dts
> index bf2cf92e8976..8897a2f4cfe3 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845-oneplus-enchilada.dts
> +++ b/arch/arm64/boot/dts/qcom/sdm845-oneplus-enchilada.dts
> @@ -12,7 +12,7 @@ / {
>  	compatible = "oneplus,enchilada", "qcom,sdm845";
>  	chassis-type = "handset";
>  	qcom,msm-id = <0x141 0x20001>;
> -	qcom,board-id = <8 0 17819 22>;
> +	qcom,board-id = <8 0>, <17819 22>;

FWIW: While it's just a cosmetic change this is a bit misleading in my
opinion. Having two tuples suggests this should be interpreted as:

"This device tree is suitable for two different boards:
 board-id = <8 0> (aka sdm845-mtp, a standard qcom reference board)
 OR, alternatively: board-id = <17819 22>"

Since this device tree is clearly not meant for sdm845-mtp one could now
argue that the <8 0> could be removed, and only the second tuple covers
the actual device. It might be worth a try (maybe Caleb can try?), but
I suspect the bootloader will not accept that...

I think the bootloader from OPPO/OnePlus is actually looking for
quadruples instead of tuples on this board. I have seen similar hacks on
several other OPPO devices as well. They usually add their project ID
(here: 17819) somewhere and look for that in the bootloader.

In this case maybe adding a short comment would be sufficient, just to
make it more obvious that this doesn't actually follow the binding
documentation.

But this kind of brings up the question if it's worth making any
constraints in the DT schema at all, if some of the device trees
can not follow it.

For example, older OPPO bootloaders actually look for triples instead,
e.g.: (This is from a real device!)
	qcom,board-id = <8 0 15009>;

So maybe it's just a matter of time until someone tries to add a DT
with a format that cannot be changed cosmetically to fit the DT schema...

Stephan

Re: [PATCH 4/4] arm64: dts: qcom: sdm845-oneplus: split qcom,board-id into tuples

[Krzysztof Kozlowski]

On 03/06/2022 21:02, Stephan Gerhold wrote:
> +Cc Caleb Connolly <caleb@connolly.tech>
> 
> On Sun, May 29, 2022 at 10:26:29PM +0200, Krzysztof Kozlowski wrote:
>> The qcom,board-id is an uint32 matrix, so a list of tuples.
>>
>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>> ---
>>  arch/arm64/boot/dts/qcom/sdm845-oneplus-enchilada.dts | 2 +-
>>  arch/arm64/boot/dts/qcom/sdm845-oneplus-fajita.dts    | 2 +-
>>  2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/sdm845-oneplus-enchilada.dts b/arch/arm64/boot/dts/qcom/sdm845-oneplus-enchilada.dts
>> index bf2cf92e8976..8897a2f4cfe3 100644
>> --- a/arch/arm64/boot/dts/qcom/sdm845-oneplus-enchilada.dts
>> +++ b/arch/arm64/boot/dts/qcom/sdm845-oneplus-enchilada.dts
>> @@ -12,7 +12,7 @@ / {
>>  	compatible = "oneplus,enchilada", "qcom,sdm845";
>>  	chassis-type = "handset";
>>  	qcom,msm-id = <0x141 0x20001>;
>> -	qcom,board-id = <8 0 17819 22>;
>> +	qcom,board-id = <8 0>, <17819 22>;
> 
> FWIW: While it's just a cosmetic change this is a bit misleading in my
> opinion. Having two tuples suggests this should be interpreted as:
> 
> "This device tree is suitable for two different boards:
>  board-id = <8 0> (aka sdm845-mtp, a standard qcom reference board)
>  OR, alternatively: board-id = <17819 22>"
> 
> Since this device tree is clearly not meant for sdm845-mtp one could now
> argue that the <8 0> could be removed, and only the second tuple covers
> the actual device. It might be worth a try (maybe Caleb can try?), but
> I suspect the bootloader will not accept that...
> 
> I think the bootloader from OPPO/OnePlus is actually looking for
> quadruples instead of tuples on this board. I have seen similar hacks on
> several other OPPO devices as well. They usually add their project ID
> (here: 17819) somewhere and look for that in the bootloader.
> 
> In this case maybe adding a short comment would be sufficient, just to
> make it more obvious that this doesn't actually follow the binding
> documentation.

Thanks for bringing up this topic. I think we should include this
quadruple-set in the DT schema.

> But this kind of brings up the question if it's worth making any
> constraints in the DT schema at all, if some of the device trees
> can not follow it.
> 
> For example, older OPPO bootloaders actually look for triples instead,
> e.g.: (This is from a real device!)
> 	qcom,board-id = <8 0 15009>;
> 
> So maybe it's just a matter of time until someone tries to add a DT
> with a format that cannot be changed cosmetically to fit the DT schema...

Generic answer is: yes, we want constraints because we want to define
interface which is followed by bootloader. Following up answer is - in
practice this might not be possible...

I wish I could say that DTS abusing bindings will not be accepted, but
unfortunately vendor (OnePlus or whoever) simply does not care at all,
so this would affect only the community. Therefore rejecting such DTS is
not a viable option which leads me to first option - try to describe it
in schema, as much as possible.

Even if it means some "oneOf:" set for different vendors.


Best regards,
Krzysztof