mirror/linux
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

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

Browse Source 
The idea impressed in the commit b32e592d3c ("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: b32e592d3c ("devicetree: bindings: Document qcom board compatible format")
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20240204-qcom-drop-compat-v1-1-69d6cd92aa0e@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
This commit is contained in:
Dmitry Baryshkov
2024-02-04 18:56:35 +02:00
committed by Bjorn Andersson
parent af53ecef19
commit 869c3d4eef
1 changed files with 5 additions and 46 deletions
Download Patch File Download Diff File Expand all files Collapse all files

51
Documentation/devicetree/bindings/arm/qcom.yaml
View File

@@ -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: