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 34924C6FA83 for ; Sun, 11 Sep 2022 11:27:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230019AbiIKL1Z (ORCPT ); Sun, 11 Sep 2022 07:27:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40540 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229937AbiIKL1X (ORCPT ); Sun, 11 Sep 2022 07:27:23 -0400 Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 73BB42E6A2 for ; Sun, 11 Sep 2022 04:27:22 -0700 (PDT) Received: by mail-lf1-x134.google.com with SMTP id q21so10482730lfo.0 for ; Sun, 11 Sep 2022 04:27:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date; bh=KGB5KUhs9u6/qzvDEhLDSbwJvVi3lKOIpjk/q5kI8ps=; b=CvzseaMTpNL08WWmVX7s3adcuwcccnU2QXIj11rOrS5xBKcte8icpKZSdxt+W5mDI+ nzMKVSj23s+VXWlO8qp7UAPs6IZ5j/A1SHXhkYbeoGiWMgkwasVB4Gczn5tGMfiwg4lI eCOFAVNsasfejci1H1HzfAqlI/eoK8kZvtivnoYvUCY30TJVPiFWCCZM6HSW4f9f1WwZ So/3MC4k1WF+frmTweMhT0k/co2JYR1+l1nRUYph97ouFJB8pGUzz5NEWU85jI8naW1e tnG0Gc42pm3lSoAS6IEDubhMwuY9PPFa31YAZ7uXdEhm3hAH/Xf+yPsL9Bg8ZYwjjVm0 hMfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date; bh=KGB5KUhs9u6/qzvDEhLDSbwJvVi3lKOIpjk/q5kI8ps=; b=J6POCIQXwFGZknXVu5AhKOF6j1TLGKVfBgk9OcIwyyp2ZsXmICetg3xVJ8zXZ2lFFL uUhNkNzlVYsvs704QJY5Z0gaDklMmJwJ/fRFr+GkeNiU4FYGWvdPmdarXU43T3bUZivh 6yrroe6pYLClQ9zd/b9hSDeyePEz+fWPYLb9LIQ5CAnrkg9S/Yg1tg9Eaj6C1zwVtz/1 Ynynh8W6mJ/zaE1PTLIYpaD0Yz4MZdxQD3l5Vleuq9lFsxkyrkUuKrJg/zdOyPqUDyv4 gUTnMYFulY+ZOUYJDScXXL5IkDML3Gwxir4PtZQP+RiDpIZpdRFz2SxSNU/djINTlUCc 8aNg== X-Gm-Message-State: ACgBeo0LPG6u76IDZ3ORQzoRJInTBKur4290FD3DcvSYoeJc5SCronKN ImJ0M4Mqjgk3d3RjiHcUEV5LCopTlam40g== X-Google-Smtp-Source: AA6agR6Ieg2VRvFOnyVF8oScDNythHwnCyh+ZOet0x7Oy3fi/OrUTbQyS4vyq9fOqLHqHoepI/i8EA== X-Received: by 2002:a05:6512:1283:b0:499:d0a3:3ca8 with SMTP id u3-20020a056512128300b00499d0a33ca8mr1706981lfs.665.1662895640833; Sun, 11 Sep 2022 04:27:20 -0700 (PDT) Received: from [192.168.0.21] (78-11-189-27.static.ip.netia.com.pl. [78.11.189.27]) by smtp.gmail.com with ESMTPSA id y26-20020a05651c221a00b0026ad1da0dc3sm618756ljq.122.2022.09.11.04.27.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 11 Sep 2022 04:27:20 -0700 (PDT) Message-ID: Date: Sun, 11 Sep 2022 13:27:19 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.13.0 Subject: Re: [PATCH v6 01/12] dt-bindings: display/msm: split qcom,mdss bindings Content-Language: en-US To: Dmitry Baryshkov Cc: Rob Herring , Andy Gross , Bjorn Andersson , Konrad Dybcio , Rob Clark , Sean Paul , Abhinav Kumar , Krzysztof Kozlowski , devicetree@vger.kernel.org, Loic Poulain , David Airlie , linux-arm-msm , dri-devel , Stephen Boyd , freedreno , AngeloGioacchino Del Regno References: <20220901102312.2005553-1-dmitry.baryshkov@linaro.org> <20220901102312.2005553-2-dmitry.baryshkov@linaro.org> <3e525135-d205-eddc-ff2d-98c8321386e3@linaro.org> <20220908193705.GA3002673-robh@kernel.org> <1ebe64a3-fab9-1dd7-517a-01001a176d9f@linaro.org> <2204eab4-b22d-8ee7-4595-49139cb387a8@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 10/09/2022 14:54, Dmitry Baryshkov wrote: >> >> However I think there is no such problem, as Dmitry said, that ref >> changes anything. There will be always failure - either from parent >> schema (using $ref) or from device child schema (the one which actually >> misses the property). > > Initially I stumbled upon this issue with the dsi and dsi_phy nodes > for msm8996 devices. If I have $ref here, dsi1/dsi1_phy nodes will > emit warnings regarding the missing -supply properties despite nodes > being disabled. If I use `compatible' here, the schema checks pass. > Thus I'd prefer to leave `compatible' here. Not to mention that it > also allows specifying a tighter binding than just using the $ref. I don't think we understood each other. I claim that error will be there anyway, just from different schema. So your change fixes nothing in total schema check... Best regards, Krzysztof