From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 94EAEC433EF for ; Sat, 11 Jun 2022 13:07:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233576AbiFKNH3 (ORCPT ); Sat, 11 Jun 2022 09:07:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55106 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233575AbiFKNH1 (ORCPT ); Sat, 11 Jun 2022 09:07:27 -0400 Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C33E23FDA8 for ; Sat, 11 Jun 2022 06:07:24 -0700 (PDT) Received: by mail-ej1-x62b.google.com with SMTP id n10so2838049ejk.5 for ; Sat, 11 Jun 2022 06:07:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=t3xj8kLCMLC4vvamPsMzSiJ2niC/wuVI+iAvhlePD7o=; b=uX6WgOkG9xeUEUQuPGDSp3BweCStVxvXtlyk0B3FBwtjym/rD9MMlngFbaQABDAmgi 9CSCdNhrnd1RvoBLmRErP9H4SmS9R2t+7PynV0tQO0+H3ZLNpi2d9Z+8c0RlW0wopeVA evrNF74tBijpawDoPa5EitKkHmeYE1lt29RO1qjFRaUtoJju9Y3nQKdxDsX2qWaf2XWM YyEURFz2dnwagNa6YWFubYUv/mV5XThSB2iagI/5Qcyt1EjmjgI0YP3nbIsaTsUWGXOE BWq8yyADYYhqDG15Y2s+JkPzgiL/gyxOIbMTV3pytHNXsWDxlvOlRSZcLdL6dklRQZWm N4IQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=t3xj8kLCMLC4vvamPsMzSiJ2niC/wuVI+iAvhlePD7o=; b=gzKXom+9ob42nQZztCQMsOOYG97pV+t5zLCkcJ+7KQhkmIwg7Z5/PmIi5czyEAYGzY J8u67HQuj0/HJhO517q8AnJt0zwWCSOTaJT0AKJseg6Ub1X/O5SuMx2kzPTFFNYQn+s5 w9MexbM0KWjNGzROeRAsmY1bfR7WD0FMBz4nshpojPRyKMz47U9EZlOME/X/yDx7Xiwe jvzRN3bAxnzXMWaZC9k1uPs433O6BpzBLMUiqA8S6ju1WnwiLiczXlCu+O2dlPoZ2zNI w6uo68d59JBS/Lz9TzLPu39FJ0VkA+kTEtg5RFx1l5KEdUpvdKfGsKIoONqPPWlihSB7 pn8A== X-Gm-Message-State: AOAM530LeR5bA4tTBAMomt87opdNLiluZqZdCL9VNemVv232FGteb8Om JVlhXtDjoAuGURQs3tKlauov2w== X-Google-Smtp-Source: ABdhPJxukTgXWKlc1cHbTbw+Z5q7M3h2i8LlNSYby1pDuVGRC9L+CC2PcCGZvNHYqZrpem+lL2G+Qw== X-Received: by 2002:a17:906:f84e:b0:70e:6ec8:cc4a with SMTP id ks14-20020a170906f84e00b0070e6ec8cc4amr37889671ejb.694.1654952843286; Sat, 11 Jun 2022 06:07:23 -0700 (PDT) Received: from [192.168.0.203] (xdsl-188-155-176-92.adslplus.ch. [188.155.176.92]) by smtp.gmail.com with ESMTPSA id 2-20020a170906318200b007121361d54asm1033191ejy.25.2022.06.11.06.07.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 11 Jun 2022 06:07:22 -0700 (PDT) Message-ID: <89d6735a-61eb-08cf-8d4a-6fb1b2d457ad@linaro.org> Date: Sat, 11 Jun 2022 15:07:21 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: [PATCH 1/4] dt-bindings: arm: qcom: document qcom,msm-id and qcom,board-id Content-Language: en-US To: Rob Herring Cc: Andy Gross , Bjorn Andersson , Krzysztof Kozlowski , linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Stephen Boyd , Konrad Dybcio , Amit Pundir , Trilok Soni , Rob Clark , Stephan Gerhold , Kumar Gala References: <20220529202629.47588-1-krzysztof.kozlowski@linaro.org> <20220529202629.47588-2-krzysztof.kozlowski@linaro.org> <20220605150747.GA3465286-robh@kernel.org> <54015d41-d4eb-12ae-5bd1-00d2c3cf7814@linaro.org> <20220610163343.GA1787330-robh@kernel.org> From: Krzysztof Kozlowski In-Reply-To: <20220610163343.GA1787330-robh@kernel.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On 10/06/2022 18:33, Rob Herring wrote: > On Tue, Jun 07, 2022 at 01:15:51PM +0200, Krzysztof Kozlowski wrote: >> On 05/06/2022 17:07, Rob Herring wrote: >>> On Sun, May 29, 2022 at 10:26:26PM +0200, Krzysztof Kozlowski wrote: >>>> The top level qcom,msm-id and qcom,board-id properties are utilized by >>>> bootloaders on Qualcomm MSM platforms to determine which device tree >>>> should be used and passed to the kernel. >>>> >>>> The commit b32e592d3c28 ("devicetree: bindings: Document qcom board >>>> compatible format") from 2015 was a consensus during discussion about >>>> upstreaming qcom,msm-id and qcom,board-id fields. There are however still >>>> problems with that consensus: >>>> 1. It was reached 7 years ago but it turned out its implementation did >>>> not reach all possible products. >>>> >>>> 2. Initially additional tool (dtbTool) was needed for parsing these >>>> fields to create a QCDT image consisting of multiple DTBs, later the >>>> bootloaders were improved and they use these qcom,msm-id and >>>> qcom,board-id properties directly. >>>> >>>> 3. Extracting relevant information from the board compatible requires >>>> this additional tool (dtbTool), which makes the build process more >>>> complicated and not easily reproducible (DTBs are modified after the >>>> kernel build). >>>> >>>> 4. Some versions of Qualcomm bootloaders expect these properties even >>>> when booting with a single DTB. The community is stuck with these >>>> bootloaders thus they require properties in the DTBs. >>>> >>>> Since several upstreamed Qualcomm SoC-based boards require these >>>> properties to properly boot and the properties are reportedly used by >>>> bootloaders, document them. >>> >>> My primary issue here is accepting this will be an endorsement for >>> other vendors doing something similar. I'm not against an ID >>> property(ies) in the root node, but would rather see something common >>> if we do anything. >> >> Hi Rob, >> >> A more common approach was merged back in 2015 - encoding this ID >> information in the board compatibles. If I understood previous >> discussion correctly, this common method was later used by Qualcomm DTB >> post-processing tool. At least for some of the cases. >> >> Other cases (several Qualcomm boards from different vendors) still use >> these ID properties. It even turns out they use it differently between >> vendors (e.g. Xiaomi vs OnePlus). >> >> Important arguments for documenting these properties: >> 1. These ID properties are already on released boards where changing >> bootloader is non-trivial or even not possible. It will not be possible >> to remove these properties, without seriously affecting the community >> working with them. > > Accepting things because they are already in use is also not a path we > want to go down. If it's the color of the bike shed, then fine. > >> 2. According to Konrad [1] (second paragraph), newer chipsets (starting >> with sm8350 released in 2021) do not use these properties. These newer >> DTS do not have them. >> >> Considering 1+2 above, maybe let's document these properties as >> compatible? Would that solve your point of "endorsement for other vendors"? > > What do you mean? Only allow them for certain root compatible strings? I > suppose that would be okay by me. It would also be useful documentation > of where they are needed. Bah, I wrote something else than I had in mind. So one more try: Considering 1+2 above, maybe let's document these properties as *deprecated*? Would that solve your point of "endorsement for other vendors"? However the idea to restrict them per-compatible, is also nice. Although I cannot guarantee the list will not grow for older SoCs. Best regards, Krzysztof