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 B0A19C433EF for ; Mon, 25 Jul 2022 17:29:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235750AbiGYR3W (ORCPT ); Mon, 25 Jul 2022 13:29:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41038 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235267AbiGYR3W (ORCPT ); Mon, 25 Jul 2022 13:29:22 -0400 Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 460AE12613 for ; Mon, 25 Jul 2022 10:29:21 -0700 (PDT) Received: by mail-lf1-x132.google.com with SMTP id b16so6627822lfb.7 for ; Mon, 25 Jul 2022 10:29:21 -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=RzKa2RWbALZsP2K2txIX8cby/e3aK0JnhlNvQouxHPY=; b=NYdlPOvLyHfwAnDwiWOFCW97w8U2PRYSfD712AzGHptvDbEb+IdAxNofpqTdaa6lJC LzFe1TNTLNV8oH+NS5NWV2VaazO/lCLoT1pL1dx1hxOujudCTfInMFRdT1HP5nnXPujz s8Gp0SZ8qCGSGGwILmnGg20R+f6W+2UkcpBCH0/r5mBYcW+dDiVrZZmA2YvKDM6fwmYO L4tuKquGq9I/m/IfCSyXYvZWRmutI0chXq/uV3yXb07upVhcgPphXX5VxvZ+lwEdAYH6 MPP5GwEmgWfUGpI237vTwwlrjBsiKdjG43cex1iA2/V3qYiZq9WOvYrpx9i5/d1C04qT K0Jw== 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=RzKa2RWbALZsP2K2txIX8cby/e3aK0JnhlNvQouxHPY=; b=YYt4NoDHJcqhpCw/o4gYquA5RWOgrGoWLKGM77iFYZG9q6olQ9FxX8qCXi8dg5rfjt YMM6y59F1H/yy+7v6hBmenHUk7rFp3sN/S8Y4qbPQ/P3GSaXZZjWrmIFyrI1y0Xl0OLH 8pTQTtOvr1KAgQLAGqh+Cn7Ooj2lYVE3yeAz7qrr6EIQOHabXNe3DH2u5ULt6H7A4cVj +SQAEuE7BJywLVXM7j8SKjDmibxN1UGrNyniehnnTjlg6n10GDM3rmbm7Di5YrMKfzA5 4d/PtysKJyxCgxwKQPkOYUJ+nSAoRx6aoV5iuQA1aMQpywaf3B1DHApEhGYPXummQrrY 4UKQ== X-Gm-Message-State: AJIora+gdZ/Es1+RbpauFVHgs4XCJ0Uyoy1QBzn95u9W6Q+kMoMPzK6w WYuQ1snSHEaCv+3Ujp7byQvohw== X-Google-Smtp-Source: AGRyM1s2gTTMuvH9HxEw8WhAv17+RDOoe0fKIl02r8CnJrOi2nTPX3mtHaax4QGUBATI0eEApxm7lQ== X-Received: by 2002:a05:6512:463:b0:48a:9605:c3e7 with SMTP id x3-20020a056512046300b0048a9605c3e7mr1242361lfd.514.1658770159482; Mon, 25 Jul 2022 10:29:19 -0700 (PDT) Received: from [192.168.3.197] (78-26-46-173.network.trollfjord.no. [78.26.46.173]) by smtp.gmail.com with ESMTPSA id t9-20020a056512208900b0048a78c1fc1dsm1980772lfr.111.2022.07.25.10.29.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 25 Jul 2022 10:29:19 -0700 (PDT) Message-ID: Date: Mon, 25 Jul 2022 19:29:17 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCH 0/3] dt-bindings: arm: qcom: define schema, not devices Content-Language: en-US To: Doug Anderson Cc: Dmitry Baryshkov , Andy Gross , Bjorn Andersson , Konrad Dybcio , Rob Herring , Krzysztof Kozlowski , linux-arm-msm , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Stephen Boyd References: <20220723090942.1637676-1-dmitry.baryshkov@linaro.org> <76defcb3-8566-286a-d953-54c4a2b04782@linaro.org> <9e012a76-aaab-9525-f3d4-8d84e26325a9@linaro.org> From: Krzysztof Kozlowski In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On 25/07/2022 19:22, Doug Anderson wrote: >>>> You cannot do that... >>> >>> The bootloader never falls back to just the SoC name. >> >> There is no "SoC" part of compatible list. Only by convenience we put it >> that way, but DT spec does not define first compatible to be for >> platform because they all are[1], therefore following your earlier >> description - bootloader should load BAR DTS on FOO device just because >> qcom,sdm845 matches. > > As documented in "Documentation/arm/google/chromebook-boot-flow.rst", > the bootloader creates a match list to pick a device tree file. It > never creates a match list that has just the SoC. It always picks > based on the board name and never falls back to just the SoC name. So this means you embedded some custom-interpretation of board compatibles in bootloader. What stops you to customize it even more, that the bootloader must always pick the most specific compatible? IOW, it cannot load DTB from more generic compatible (just like it should not load qcom,sdm845 DTS)? I understand the limitation of board compatibles for your case, but I still believe it is wrong usage of it. If the usage - by principle - was correct, then you would not need to add the restriction you mentioned above ("never creates a match list that has just the SoC"). Because when Linux drivers match, they do not have such restriction... Best regards, Krzysztof