From: Rob Herring <robh@kernel.org>
To: Amrit Anand <quic_amrianan@quicinc.com>
Cc: krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org,
agross@kernel.org, andersson@kernel.org,
konrad.dybcio@linaro.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
kernel@quicinc.com, Elliot Berman <quic_eberman@quicinc.com>
Subject: Re: [PATCH 1/2] dt-bindings: hwinfo: Introduce board-id
Date: Wed, 24 Jan 2024 09:00:02 -0600 [thread overview]
Message-ID: <20240124150002.GB873781-robh@kernel.org> (raw)
In-Reply-To: <1705749649-4708-2-git-send-email-quic_amrianan@quicinc.com>
On Sat, Jan 20, 2024 at 04:50:48PM +0530, Amrit Anand wrote:
> From: Elliot Berman <quic_eberman@quicinc.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@quicinc.com>
> Signed-off-by: Amrit Anand <quic_amrianan@quicinc.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@quicinc.com>
> + - Elliot Berman <quic_eberman@quicinc.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
This is not how #foo-cells works. It is for provider/consumer style
bindings.
Rob
next prev parent reply other threads:[~2024-01-24 15:00 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-20 11:20 [PATCH 0/2] Add board-id support for multiple DT selection Amrit Anand
2024-01-20 11:20 ` [PATCH 1/2] dt-bindings: hwinfo: Introduce board-id Amrit Anand
2024-01-20 12:36 ` Rob Herring
2024-01-20 19:10 ` Trilok Soni
2024-01-22 10:10 ` Amrit Anand
2024-01-23 11:50 ` Krzysztof Kozlowski
2024-01-23 17:18 ` Conor Dooley
2024-01-23 18:51 ` Elliot Berman
2024-01-23 20:05 ` Trilok Soni
2024-01-24 12:44 ` Amrit Anand
2024-01-23 12:09 ` Krzysztof Kozlowski
2024-01-24 12:42 ` Amrit Anand
2024-01-25 10:40 ` Krzysztof Kozlowski
2024-01-24 15:00 ` Rob Herring [this message]
2024-01-20 11:20 ` [PATCH 2/2] dt-bindings: hwinfo: Add Qualcomm's board-id types Amrit Anand
2024-01-20 12:36 ` Rob Herring
2024-01-20 13:32 ` Konrad Dybcio
2024-01-22 10:07 ` Amrit Anand
2024-01-22 18:10 ` Elliot Berman
2024-01-22 19:27 ` Dmitry Baryshkov
2024-01-24 12:47 ` Amrit Anand
2024-01-21 2:05 ` kernel test robot
2024-01-22 18:12 ` Elliot Berman
2024-01-20 13:04 ` [PATCH 0/2] Add board-id support for multiple DT selection Konrad Dybcio
2024-01-22 17:50 ` Elliot Berman
2024-01-24 14:56 ` Rob Herring
2024-02-02 5:00 ` Amrit Anand
2024-02-14 12:56 ` Amrit Anand
2024-02-14 13:12 ` Krzysztof Kozlowski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240124150002.GB873781-robh@kernel.org \
--to=robh@kernel.org \
--cc=agross@kernel.org \
--cc=andersson@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=kernel@quicinc.com \
--cc=konrad.dybcio@linaro.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=quic_amrianan@quicinc.com \
--cc=quic_eberman@quicinc.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.