| Message ID | 20240204-qcom-drop-compat-v1-1-69d6cd92aa0e@linaro.org |
|---|---|
| State | Accepted |
| Commit | 869c3d4eef65f3daf2f7a3a4155655f76a11eb87 |
| Headers | show |
| Series | dt-bindings: arm: qcom: drop the superfluous device compatibility schema | expand |
On Sun, Feb 04, 2024 at 06:56:35PM +0200, Dmitry Baryshkov wrote: > The idea impressed in the commit b32e592d3c28 ("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: b32e592d3c28 ("devicetree: bindings: Document qcom board compatible format") > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Bjorn Andersson <andersson@kernel.org> Regards, Bjorn
On Sun, 04 Feb 2024 18:56:35 +0200, Dmitry Baryshkov wrote: > The idea impressed in the commit b32e592d3c28 ("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. > > [...] Applied, thanks! [1/1] dt-bindings: arm: qcom: drop the superfluous device compatibility schema commit: 869c3d4eef65f3daf2f7a3a4155655f76a11eb87 Best regards,
On Sun, Feb 04, 2024 at 06:56:35PM +0200, Dmitry Baryshkov wrote: > The idea impressed in the commit b32e592d3c28 ("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: b32e592d3c28 ("devicetree: bindings: Document qcom board compatible format") FWIW: It's not correct that no device uses the version parts of the compatible string. There are actually two boards documented in qcom.yaml that follow this scheme: compatible = "qcom,msm8916-mtp", "qcom,msm8916-mtp/1", "qcom,msm8916"; compatible = "longcheer,l8150", "qcom,msm8916-v1-qrd/9-v1", "qcom,msm8916"; I don't think anyone is actively relying on those, though. I guess we can just ignore them or even remove them. Thanks, Stephan
On Sun, 11 Feb 2024 at 12:36, Stephan Gerhold <stephan@gerhold.net> wrote: > > On Sun, Feb 04, 2024 at 06:56:35PM +0200, Dmitry Baryshkov wrote: > > The idea impressed in the commit b32e592d3c28 ("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: b32e592d3c28 ("devicetree: bindings: Document qcom board compatible format") > > FWIW: It's not correct that no device uses the version parts of the > compatible string. There are actually two boards documented in qcom.yaml > that follow this scheme: > > compatible = "qcom,msm8916-mtp", "qcom,msm8916-mtp/1", "qcom,msm8916"; > compatible = "longcheer,l8150", "qcom,msm8916-v1-qrd/9-v1", "qcom,msm8916"; > > I don't think anyone is actively relying on those, though. I guess we > can just ignore them or even remove them. Excuse me for the long delay. As it was you who added the longcheer-l8150 support, does it require any of the msm-id options or dtbTool (original or modified) processing? If it can work with no additional tags, we can drop these compatibility strings.
On Tue, Feb 20, 2024 at 11:11:15AM +0200, Dmitry Baryshkov wrote: > On Sun, 11 Feb 2024 at 12:36, Stephan Gerhold <stephan@gerhold.net> wrote: > > On Sun, Feb 04, 2024 at 06:56:35PM +0200, Dmitry Baryshkov wrote: > > > The idea impressed in the commit b32e592d3c28 ("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: b32e592d3c28 ("devicetree: bindings: Document qcom board compatible format") > > > > FWIW: It's not correct that no device uses the version parts of the > > compatible string. There are actually two boards documented in qcom.yaml > > that follow this scheme: > > > > compatible = "qcom,msm8916-mtp", "qcom,msm8916-mtp/1", "qcom,msm8916"; > > compatible = "longcheer,l8150", "qcom,msm8916-v1-qrd/9-v1", "qcom,msm8916"; > > > > I don't think anyone is actively relying on those, though. I guess we > > can just ignore them or even remove them. > > Excuse me for the long delay. As it was you who added the > longcheer-l8150 support, does it require any of the msm-id options or > dtbTool (original or modified) processing? > If it can work with no additional tags, we can drop these compatibility strings. > I think we added it back then to allow booting mainline with the original bootloader. Together with the "skales" dtbTool (used to be at https://source.codeaurora.org/quic/kernel/skales) the compatible does result in a correct QCDT that is accepted by the bootloader. I doubt anyone still uses this way of booting nowadays. In postmarketOS we strongly recommend everyone to boot MSM8916 devices using lk2nd [1] which supports plain appended DTB without special properties and other more reliable forms of DTB selection. I have not tested booting mainline with the original bootloader for many years. Dropping the extra compatible would be fine for me. Personally I don't consider booting via weird/broken bootloaders worth supporting (at least if better workarounds exist). Having to boot with "custom" bootloaders tends to be a somewhat subjective topic though so others might disagree. Thanks, Stephan [1]: https://github.com/msm8916-mainline/lk2nd
On Tue, 20 Feb 2024 at 23:11, Stephan Gerhold <stephan@gerhold.net> wrote: > > On Tue, Feb 20, 2024 at 11:11:15AM +0200, Dmitry Baryshkov wrote: > > On Sun, 11 Feb 2024 at 12:36, Stephan Gerhold <stephan@gerhold.net> wrote: > > > On Sun, Feb 04, 2024 at 06:56:35PM +0200, Dmitry Baryshkov wrote: > > > > The idea impressed in the commit b32e592d3c28 ("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: b32e592d3c28 ("devicetree: bindings: Document qcom board compatible format") > > > > > > FWIW: It's not correct that no device uses the version parts of the > > > compatible string. There are actually two boards documented in qcom.yaml > > > that follow this scheme: > > > > > > compatible = "qcom,msm8916-mtp", "qcom,msm8916-mtp/1", "qcom,msm8916"; > > > compatible = "longcheer,l8150", "qcom,msm8916-v1-qrd/9-v1", "qcom,msm8916"; > > > > > > I don't think anyone is actively relying on those, though. I guess we > > > can just ignore them or even remove them. > > > > Excuse me for the long delay. As it was you who added the > > longcheer-l8150 support, does it require any of the msm-id options or > > dtbTool (original or modified) processing? > > If it can work with no additional tags, we can drop these compatibility strings. > > > > I think we added it back then to allow booting mainline with the > original bootloader. Together with the "skales" dtbTool (used to be at > https://source.codeaurora.org/quic/kernel/skales) the compatible does > result in a correct QCDT that is accepted by the bootloader. > > I doubt anyone still uses this way of booting nowadays. In postmarketOS > we strongly recommend everyone to boot MSM8916 devices using lk2nd [1] > which supports plain appended DTB without special properties and other > more reliable forms of DTB selection. I have not tested booting mainline > with the original bootloader for many years. If I remember correctly, if somebody wants to boot msm8916 with the 'original' bootloader, they will also face issues with SMP support, etc. So let's drop that. > Dropping the extra compatible would be fine for me. Personally I don't > consider booting via weird/broken bootloaders worth supporting (at least > if better workarounds exist). Having to boot with "custom" bootloaders > tends to be a somewhat subjective topic though so others might disagree. I usually prefer to stick to the original as much as possible, especially for the end-user devices. But in this case I think it's beyond possible.
diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml index 1999a5f2f254..2b993b4c51dc 100644 --- a/Documentation/devicetree/bindings/arm/qcom.yaml +++ b/Documentation/devicetree/bindings/arm/qcom.yaml @@ -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:
The idea impressed in the commit b32e592d3c28 ("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: b32e592d3c28 ("devicetree: bindings: Document qcom board compatible format") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> --- Documentation/devicetree/bindings/arm/qcom.yaml | 51 +++---------------------- 1 file changed, 5 insertions(+), 46 deletions(-) --- base-commit: 076d56d74f17e625b3d63cf4743b3d7d02180379 change-id: 20240204-qcom-drop-compat-6c21c9e1f907 Best regards,