Commit 869c3d4e authored by Dmitry Baryshkov's avatar Dmitry Baryshkov Committed by Bjorn Andersson

dt-bindings: arm: qcom: drop the superfluous device compatibility schema

The idea impressed in the commit b32e592d ("devicetree: bindings:
Document qcom board compatible format") never got actually adopted. As
can be seen from the existing board DT files, no device actually used
the PMIC / foundry / version parts of the compatible string. Drop this
compatibility string description to avoid possible confusion and keep
just the generic terms and the SoC list.

Fixes: b32e592d ("devicetree: bindings: Document qcom board compatible format")
Signed-off-by: default avatarDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: default avatarKrzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: default avatarBjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20240204-qcom-drop-compat-v1-1-69d6cd92aa0e@linaro.orgSigned-off-by: default avatarBjorn Andersson <andersson@kernel.org>
parent af53ecef
......@@ -10,17 +10,10 @@ maintainers:
- Bjorn Andersson <bjorn.andersson@linaro.org>
description: |
Some qcom based bootloaders identify the dtb blob based on a set of
device properties like SoC and platform and revisions of those components.
To support this scheme, we encode this information into the board compatible
string.
Each board must specify a top-level board compatible string with the following
format:
compatible = "qcom,<SoC>[-<soc_version>][-<foundry_id>]-<board>[/<subtype>][-<board_version>]"
The 'SoC' and 'board' elements are required. All other elements are optional.
For devices using the Qualcomm SoC the "compatible" properties consists of
one or several "manufacturer,model" strings, describing the device itself,
followed by one or several "qcom,<SoC>" strings, describing the SoC used in
the device.
The 'SoC' element must be one of the following strings:
......@@ -90,43 +83,9 @@ description: |
sm8650
x1e80100
The 'board' element must be one of the following strings:
adp
cdp
dragonboard
idp
liquid
mtp
qcp
qrd
rb2
ride
sbc
x100
The 'soc_version' and 'board_version' elements take the form of v<Major>.<Minor>
where the minor number may be omitted when it's zero, i.e. v1.0 is the same
as v1. If all versions of the 'board_version' elements match, then a
wildcard '*' should be used, e.g. 'v*'.
The 'foundry_id' and 'subtype' elements are one or more digits from 0 to 9.
Examples:
"qcom,msm8916-v1-cdp-pm8916-v2.1"
A CDP board with an msm8916 SoC, version 1 paired with a pm8916 PMIC of version
2.1.
"qcom,apq8074-v2.0-2-dragonboard/1-v0.1"
A dragonboard board v0.1 of subtype 1 with an apq8074 SoC version 2, made in
foundry 2.
There are many devices in the list below that run the standard ChromeOS
bootloader setup and use the open source depthcharge bootloader to boot the
OS. These devices do not use the scheme described above. For details, see:
OS. These devices use the bootflow explained at
https://docs.kernel.org/arch/arm/google/chromebook-boot-flow.html
properties:
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment