Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp4419684iob; Sun, 8 May 2022 12:07:04 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxP2jQnr0wwUbVJlLoKzGxHTZFSQbIHL7TgjbMyelIQP/CDggKn7qw3CiRR8uxdOcrbNQFq X-Received: by 2002:a05:6402:289a:b0:425:d682:105d with SMTP id eg26-20020a056402289a00b00425d682105dmr14196260edb.175.1652036824460; Sun, 08 May 2022 12:07:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652036824; cv=none; d=google.com; s=arc-20160816; b=h0gB53sSe/5xYYAe9I/J2lY3Y2Swb4x78+jqGM0cqYoZKaF3jGCkeMPirBr8eP7GjP 2qNuwKRX7bhOBeSdWwSKyqu+E4UPAAmN16fcmRr4mPPsOGIXWuqea/xUmylM+XlU2G// su2H2MwxZoOzZXJJEZ/VY4ZemmnCATGu4LXXBTTo8oU8NIXeUcCaQZi959f/SqcDTLhn WLR00oiHjDQfIkSDNQapVKgyyMGfEQAIoN/eld9MteLbZgqb0t/ebCBrYNxYpr8KCcKJ c8yifkYJI2fKXUB/Bs+c0gOzGSfwi8z4OR3et/B7WcE/GUeMcjRg36HY/rihdr6eJ+L1 ikrA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=lwpxPEc/qAOut1rsLlLVEixk6aV+q5P8g2o44/7tBWU=; b=WIjKIAFz0hMw3wLvH8UE6pcjxZ7wBpV2FayoF+uOqZ0JZC0cWB9TgFc2iOAUjtIRmS M+zlovh3N5i4vbOq7n3zPG13q4jKYoUoX0Blq/u0BEzbkUq2m1oUorERRuU8Ybr56tK0 DmLFaNG1K7EkojNZvuVM9E3jiGfkKfHTtaFxhYet2ZE4N3+Qc6cc0Fa4OpnBAlJp2bvt DJU1FaI3mspqflJRhxOQatSguVXkvomO85OdlMqtJdb42NdJnayknoqDKn736WDzNQNA 4Gpg1wGdZsfpkh9t1hqlqdE68lluPJNHR8DYqYp5NrHN/yasQSMHwIvURhFvifVtsp+i Fe9g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=hzDfCTXE; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id z1-20020a170906814100b006e7cd47a2d3si10604079ejw.189.2022.05.08.12.06.40; Sun, 08 May 2022 12:07:04 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=hzDfCTXE; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1392192AbiEGRIK (ORCPT + 99 others); Sat, 7 May 2022 13:08:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58588 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232817AbiEGRIG (ORCPT ); Sat, 7 May 2022 13:08:06 -0400 Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C07501A806 for ; Sat, 7 May 2022 10:04:17 -0700 (PDT) Received: by mail-ej1-x635.google.com with SMTP id i19so19630460eja.11 for ; Sat, 07 May 2022 10:04:17 -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=lwpxPEc/qAOut1rsLlLVEixk6aV+q5P8g2o44/7tBWU=; b=hzDfCTXEzXCF8HEY4rk18UbzbaY08fbqWhedXjN6W7tlWX/Av1LXsp1d3ji3U3sdKW nmdjCoedC078cUYNfik7TUpcdlw89WgAYGv0eruUwAgJ6E7ei7kd6ZANzp4ZYDaUOIia Jj4YhKnzz26l5mv5i/X8I133uguvVAkMS772eR5Qj2SmvAFk7oifyT/ZBaJa64BLEAwm asbdvTBMIwBvfV6+t4vtg8/q/wUI5WWEyNRnw15MJfvPcXJh929mSKPX92yqAqHxLu9/ Q2A/WIIRbDeFOtnPJrZ31WjO2Z2KVqBkEDC0RX+VSf3V+XbuoSbPYuO1dyFCBYzA5Of8 jvjQ== 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=lwpxPEc/qAOut1rsLlLVEixk6aV+q5P8g2o44/7tBWU=; b=FlDONF8a4vxvjpV2v4YWB2RkPtVmZOzBUcfO+rdr0UAY0UUs422GJPlfacK41YpBtK Ptj/EWbfdofcUSMvBRe7YCu2GkPnyFKCjF59YTcuK0FeTxaRW8VEECSgwEW1fqDqJqyo FTO9cY88EHOj/v9kJhoV2cmLHnZkZAmELLU0e3BRSjYbAlHerS8LVPCcyddRn/brigmp KubV1w4/HDBDTRMfbq/hrjCRkmKT6IOgvENVjNgorcOP6pRc/ThGG67u7wP3abUfXcuT gcHWvhSCzwHv3G/EQ7MQKTrRohe3jfHU73qom2BCMiwpExy9LQ1AF+UVvv6qawtYoujc ID/A== X-Gm-Message-State: AOAM531t5Y6lzPA/i1FTrmZLKwMucSy4ZwKN/Sn7Ww+GCZhe8Gq1WTES uA5AwMyrhuCN3AJVI77EHu4jjcG/4169ABa3 X-Received: by 2002:a17:906:f857:b0:6f3:a331:c043 with SMTP id ks23-20020a170906f85700b006f3a331c043mr7616353ejb.246.1651943056251; Sat, 07 May 2022 10:04:16 -0700 (PDT) Received: from [192.168.0.233] (xdsl-188-155-176-92.adslplus.ch. [188.155.176.92]) by smtp.gmail.com with ESMTPSA id g10-20020aa7dc4a000000b0042617ba63basm3697642edu.68.2022.05.07.10.04.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 07 May 2022 10:04:15 -0700 (PDT) Message-ID: Date: Sat, 7 May 2022 19:04:14 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: [PATCH] CHROMIUM: arm64: dts: qcom: Add sc7180-gelarshie Content-Language: en-US To: Doug Anderson Cc: =?UTF-8?Q?Krzysztof_Koz=c5=82owski?= , Mars Chen , Andy Gross , Bjorn Andersson , Rob Herring , Krzysztof Kozlowski , linux-arm-msm , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , LKML , Julius Werner References: <20220330090947.9100-1-chenxiangrui@huaqin.corp-partner.google.com> <606cc762-a0c2-49a4-3e5d-d2dbd4595bc7@linaro.org> From: Krzysztof Kozlowski In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/05/2022 23:33, Doug Anderson wrote: > Hi, > > On Wed, May 4, 2022 at 12:04 AM Krzysztof Kozlowski > wrote: >> >>>>>> The most specific compatible identifies or, like recently Rob confirmed >>>>>> in case of Renesas, the list of compatibles: >>>>>> https://lore.kernel.org/linux-devicetree/Yk2%2F0Jf151gLuCGz@robh.at.kernel.org/ >>>>> >>>>> I'm confused. If the device tree contains the compatibles: >>>>> >>>>> "google,lazor-rev4", "google,lazor-rev3", "google,lazor", "qualcomm,sc7180" >>>>> >>>>> You want to know what board you're on and you look at the compatible, >>>>> right? You'll decide that you're on a "google,lazor-rev4" which is the >>>>> most specific compatible. ...but you could have booted a >>>>> "google,lazor-rev3". How do you know? >>>> >>>> Applying the wrong DTB on the wrong device will always give you the >>>> wrong answer. You can try too boot google,lazor-rev3 on x86 PC and it >>>> does not make it a google,lazor-rev3... >>> >>> I don't understand what you're saying here. If a device tree has the compatible: >>> >>> "google,lazor-rev4", "google,lazor-rev3", "google,lazor", "qualcomm,sc7180" >>> >>> You wouldn't expect to boot it on an x86 PC, but you would expect to >>> boot it on either a "google,lazor-rev4" _or_ a "google,lazor-rev3". >> >> Yes, but booting it does not mean that the hardware is rev3 or rev4. >> Booting it means only that we are running DTB on a compatible hardware. >> The DTB determines what is accessible to user-space, not what *really* >> the hardware is. The user-space (since we are going now to original >> question) reads it and can understand that it is running on hardware >> compatible with rev3 - either rev3 or rev4 - and act accordingly. >> >>> Correct? Now, after we've booted software wants to look at the >>> compatible of the device tree that was booted. The most specific entry >>> in that device tree is "google,lazor-rev4". ...but we could have >>> booted it on a "google,lazor-rev3". How can you know? >> >> No, providing and loading a rev4 DTB on a rev3 board is not correct and >> does not make any sense. rev3 boards are not compatible with rev4, it's >> the other way. Not every fruit is an apple, but every apple is a fruit. >> This is why I used that example - if you load rev4 DTB on rev3 hardware >> then you have totally wrong booting process. > > I think this is the crux of the difference in opinion and there's no > reasonable way I'm aware of to do what you're asking. If -rev3 and > -rev4 are identical from a software point of view it would be silly > not to share a device tree for the two of them. The number of device > trees we'd have to land in the kernel tree would be multiplied by > several times and we'd have many that are identical except for this > compatible string. I see no benefit here and lots of downside. Wait, we agreed that you don't consider them identical, didn't we? If they are identical, you do not need rev4 at all. So they are not identical... If they are identical, just use rev3 and problem is gone. If they are not identical or you need to assume there will be difference (for future), then just go with rev3 without fallback to rev3 and also problem is gone. Right now it's not possible to validate QCOM DTSes against DT bindings because they throw big fat warnings about undocumented top compatibles. This is a downside for us. Remember, you do not have to use Devicetree or Linux at all if it causes you some downsides... No one is forced. :) If you choose to use it, sorry, it comes with some requirements like being following Devicetree specification or the binding guidelines. Best regards, Krzysztof