Message-ID: <1705749649-4708-2-git-send-email-quic_amrianan@quicinc.com>
Date: Sat, 20 Jan 2024 16:50:48 +0530
From: Amrit Anand <quic_amrianan@...cinc.com>
To: <robh+dt@...nel.org>, <krzysztof.kozlowski+dt@...aro.org>,
        <conor+dt@...nel.org>, <agross@...nel.org>, <andersson@...nel.org>,
        <konrad.dybcio@...aro.org>
CC: <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <linux-arm-msm@...r.kernel.org>, <kernel@...cinc.com>,
        Elliot Berman
	<quic_eberman@...cinc.com>,
        Amrit Anand <quic_amrianan@...cinc.com>
Subject: [PATCH 1/2] dt-bindings: hwinfo: Introduce board-id

From: Elliot Berman <quic_eberman@...cinc.com>

Device manufacturers frequently ship multiple boards or SKUs under a
single software package. These software packages will ship multiple
devicetree blobs and require some mechanism to pick the correct DTB for
the board the software package was deployed. Introduce a common
definition for adding board identifiers to device trees. board-id
provides a mechanism for bootloaders to select the appropriate DTB which
is vendor/OEM-agnostic.

Isn't that what the compatible property is for?
-----------------------------------------------
The compatible property can be used for board matching, but requires
bootloaders and/or firmware to maintain a database of possible strings
to match against or have complex compatible string matching. Compatible
string matching becomes complicated when there are multiple versions of
board: the device tree selector should recognize a DTB that cares to
distinguish between v1/v2 and a DTB that doesn't make the distinction.
An eeprom either needs to store the compatible strings that could match
against the board or the bootloader needs to have vendor-specific
decoding logic for the compatible string. Neither increasing eeprom
storage nor adding vendor-specific decoding logic is desirable.

The solution proposed here is simpler to implement and doesn't require
updating firmware or bootloader for every new board.

How is this better than Qualcomm's qcom,msm-id/qcom,board-id?
-------------------------------------------------------------
The selection process for devicetrees was Qualcomm-specific and not
useful for other devices and bootloaders that were not developed by
Qualcomm because a complex algorithm was used to implement. Board-ids
provide a matching solution that can be implemented by bootloaders
without introducing vendor-specific code. Qualcomm uses three
devicetree properties: msm-id (interchangeably: soc-id), board-id, and
pmic-id.  This does not scale well for use casese which use identifiers,
for example, to distinguish between a display panel. For a display
panel, an approach could be to add a new property: display-id,
but now	bootloaders need to be updated to also read this property. We
want to	avoid requiring to update bootloaders with new hardware
identifiers: a bootloader need only recognize the identifiers it can
handle.

Signed-off-by: Elliot Berman <quic_eberman@...cinc.com>
Signed-off-by: Amrit Anand <quic_amrianan@...cinc.com>
---
 .../devicetree/bindings/hwinfo/board-id.yaml       | 53 ++++++++++++++++++++++
 1 file changed, 53 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwinfo/board-id.yaml

diff --git a/Documentation/devicetree/bindings/hwinfo/board-id.yaml b/Documentation/devicetree/bindings/hwinfo/board-id.yaml
new file mode 100644
index 0000000..82d5ff7
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwinfo/board-id.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwinfo/board-id.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Board Identifier for Devicetree Selection
+
+maintainers:
+  - Amrit Anand <quic_amrianan@...cinc.com>
+  - Elliot Berman <quic_eberman@...cinc.com>
+
+description: |
+  Device manufacturers frequently ship multiple boards under a single
+  software package. These software packages will ship multiple devicetree
+  blobs and require some mechanism to pick the correct DTB for the board
+  the software package was deployed. board-id provides a mechanism for
+  bootloaders to select the appropriate DTB which is vendor/OEM-agnostic.
+
+select:
+  anyOf:
+    - required:
+        - 'board-id'
+    - required:
+        - 'board-id-types'
+    - required:
+        - '#board-id-cells'
+
+properties:
+  $nodename:
+    const: "/"
+  board-id:
+    $ref: /schemas/types.yaml#/definitions/uint32-matrix
+    description: |
+      A list of identifiers that can be used to match with this devicetree.
+      The interpretatation of each cell can be matched with the
+      board-id-type at the same index.
+
+  board-id-types:
+    $ref: /schemas/types.yaml#/definitions/non-unique-string-array
+    description:
+      Defines the type of each cell, indicating to the DeviceTree selection
+      mechanism how to parse the board-id.
+
+  '#board-id-cells':
+    minimum: 1
+
+required:
+  - board-id
+  - board-id-types
+  - '#board-id-cells'
+
+additionalProperties: true
-- 
2.7.4

Powered by blists - more mailing lists