Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp1157167ybl; Wed, 29 Jan 2020 16:32:24 -0800 (PST) X-Google-Smtp-Source: APXvYqxwaboFKUOgwfDn9FmznPGZJHn6/3/Xb9HvvmJCt9oym2Zfr0tr65K8MMgHqHIvwf+BQnR7 X-Received: by 2002:a54:4896:: with SMTP id r22mr1209584oic.30.1580344344008; Wed, 29 Jan 2020 16:32:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1580344344; cv=none; d=google.com; s=arc-20160816; b=KTKqXCLv+4Dv402FWM68VVpS3XDvianZ7V0kkg0fvxWMuBINHIGLk/zuUpdi5ty6fQ CdnPmhMg9f5l2kb1i8IT8MAUyEdOu6mBc280vGdkcUrDRTX1x/EbytpyvvfBV1PC4Zwg 8bLz+g1En2SyMlGDr0u/08/zUHIZh3g6MlqLdoqVqyfWNZZQ14BffMe+G09QwP2MiKS/ 4PXWimMJ1ftUW/R4R7oBy7l1U6O6tjXuuIt1NepET7ffOvnwgZQga6e6LWjNbGrO8tNn C2ISucR+y+Mc5F2Pd1AQmMYaKim67kNqEhJX4UJWnZuogEh+Q9WmzDmLqaVpheXr+leT krwg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=HPkGA3GK3blVdQi8+NIYhn2wAG+9S/XJZPz8vvp4cLo=; b=ma6gBRbFAMmEryHO6JnHrK+kfRnbc4PW4fzEmeJ5bj93V0np8Zhy0ytoqlOmjpJDOI yLS9vkfKeu6W7MLW1lnxI3A2wtYWZ/5734y54lsI5DJq91VfjDfqKYWXerSmE7HEK3Um Qb9R8nlnYB+CW0gdT1fchwXmJV1SpItjn1V6sDVCQw2mCVXl55iWxbgEoSEiyeVq8+c0 W7HMETrj95Z1T5LlTfCZPMi2V7hYjXxULA6EoW+VBra6l1aFCWll7bew/bFRNPRQKogg zSjNUIFFnEZcKwq8CkfimhyXtAzbcKb4fHxmOPmDjQOOpXK3ftn+XkiHnP07RecSqfoW VJbQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=M6sCkftY; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m14si1992793otr.131.2020.01.29.16.32.11; Wed, 29 Jan 2020 16:32:23 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=M6sCkftY; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727227AbgA3AbG (ORCPT + 99 others); Wed, 29 Jan 2020 19:31:06 -0500 Received: from mail-vk1-f196.google.com ([209.85.221.196]:44810 "EHLO mail-vk1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726401AbgA3AbG (ORCPT ); Wed, 29 Jan 2020 19:31:06 -0500 Received: by mail-vk1-f196.google.com with SMTP id y184so531149vkc.11 for ; Wed, 29 Jan 2020 16:31:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HPkGA3GK3blVdQi8+NIYhn2wAG+9S/XJZPz8vvp4cLo=; b=M6sCkftYdw+yxCZolQLugqQz0RovdHNk6PaR2tvafsXWi2mt6BF6Ldsv8+gYeZxs4Y T2tWoq+ubinXa1WQmLOIo4QqMm2Q2BQMVBcF/P7CTCZTe0tWMlAeT7Guo+gsC2Doi5Vb boHynzCL0K0eWTW5QtPEO9/8SJrt4pkwf46fw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HPkGA3GK3blVdQi8+NIYhn2wAG+9S/XJZPz8vvp4cLo=; b=Ibk1CrD6lpJirQvHVIrhj24v7sGJ2T9waFruIe44nu4uVexzTYKCzdfVu80V0crIs/ s3aH881KaY+4ggstXadV+I70VvEmU2AyFi/HnzpPE7uPVxkUsVKkMxvHPwfPgZOui7Qp iM/kJN14Wa1sgSWpXh20G/212sKv07ksQhD+ujpOFxuSHkNw0mbaGQBSfqQZN8/HfzG/ uVfqZ+NSsiXVKxxOCAZ2WxnbVwW17/WFUx7cLWfOfhrX2YwzQsnMiXDmq1RxvPQ4Ym7S TIrB+XXuTqq/5p9hDhkLM1RGR71XTt5okILGS4CgSKci+p99YcrwrqVXmw0eRCaHTbj/ jA0A== X-Gm-Message-State: APjAAAVLTozuqihU7DCgFPMAu6KaiRPczuwRvugXPtf698EHXlst8E0E 9tWwC6s3Jr7Ti8qhIFPqPh4L1u4/s6c= X-Received: by 2002:a1f:28cd:: with SMTP id o196mr1260911vko.87.1580344264528; Wed, 29 Jan 2020 16:31:04 -0800 (PST) Received: from mail-vk1-f177.google.com (mail-vk1-f177.google.com. [209.85.221.177]) by smtp.gmail.com with ESMTPSA id z15sm952099vsz.27.2020.01.29.16.31.03 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 29 Jan 2020 16:31:04 -0800 (PST) Received: by mail-vk1-f177.google.com with SMTP id c129so539934vkh.7 for ; Wed, 29 Jan 2020 16:31:03 -0800 (PST) X-Received: by 2002:a1f:c686:: with SMTP id w128mr1285411vkf.34.1580343865022; Wed, 29 Jan 2020 16:24:25 -0800 (PST) MIME-Version: 1.0 References: <20200129132313.1.I4452dc951d7556ede422835268742b25a18b356b@changeid> In-Reply-To: From: Doug Anderson Date: Wed, 29 Jan 2020 16:24:10 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] dt-bindings: clk: qcom: Fix self-validation, split, and clean cruft To: Rob Herring Cc: Stephen Boyd , Taniya Das , Jeffrey Hugo , Abhishek Sahu , sivaprak@codeaurora.org, anusharao@codeaurora.org, Sricharan , Bjorn Andersson , Michael Turquette , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , linux-arm-msm , "linux-kernel@vger.kernel.org" , Andy Gross , Mark Rutland , linux-clk Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Wed, Jan 29, 2020 at 3:50 PM Rob Herring wrote: > > On Wed, Jan 29, 2020 at 5:26 PM Doug Anderson wrote: > > > > Hi, > > > > On Wed, Jan 29, 2020 at 2:01 PM Rob Herring wrote: > > > > > > On Wed, Jan 29, 2020 at 3:23 PM Douglas Anderson wrote: > > > > > > > > The 'qcom,gcc.yaml' file failed self-validation (dt_binding_check) > > > > because it required a property to be either (3 entries big), > > > > (3 entries big), or (7 entries big), but not more than one of those > > > > things. That didn't make a ton of sense. > > > > > > > > This patch splits all of the exceptional device trees (AKA those that > > > > would have needed if/then/else rules) from qcom,gcc.yaml. It also > > > > cleans up some cruft found while doing that. > > > > > > > > After this lands, this worked for me atop clk-next: > > > > for f in \ > > > > Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml \ > > > > Documentation/devicetree/bindings/clock/qcom,gcc-ipq8074.yaml \ > > > > Documentation/devicetree/bindings/clock/qcom,gcc-msm8996.yaml \ > > > > Documentation/devicetree/bindings/clock/qcom,gcc-msm8998.yaml \ > > > > Documentation/devicetree/bindings/clock/qcom,gcc-qcs404.yaml \ > > > > Documentation/devicetree/bindings/clock/qcom,gcc-sc7180.yaml \ > > > > Documentation/devicetree/bindings/clock/qcom,gcc-sm8150.yaml \ > > > > Documentation/devicetree/bindings/clock/qcom,gcc.yaml; do \ > > > > ARCH=arm64 make dt_binding_check DT_SCHEMA_FILES=$f; \ > > > > ARCH=arm64 make dtbs_check DT_SCHEMA_FILES=$f; \ > > > > done > > > > > > Note that using DT_SCHEMA_FILES may hide some errors in examples as > > > all other schemas (including the core ones) are not used for > > > validation. So just 'make dt_binding_check' needs to pass (ignoring > > > any other unrelated errors as it breaks frequently). Supposedly a > > > patch is coming explaining this in the documentation. > > > > That seems like it's going to be a huge pain going forward, but OK. > > Use of DT_SCHEMA_FILES hiding problems or having to run 'make > dt_binding_check' on everything? Having to run 'make dt_binding_check' on everything. I guess maybe if the tree stays clean it won't be too bad and it wasn't too bad against the current linux-next, but I can imagine that every time I want to run this I'll run into a pile of warnings / errors in other people's files. Then I need to figure out what to ignore / workaround. If something fails badly (like intel-gw-pcie.yaml) I'll have to realize that I should just delete that file to get the rest of the run to report errors that are relevant to me. This'll probably be worse because most maintainer trees are based on "-rc1" and at least in the past I've found that "-rc1" tends to have lots of problems. Each maintainer then fixes the problems relative to their own subsystem, but it's not a wonderful thing to rely on. > I could probably rework things such that you can check a single > binding example against all schema, but dtbs still get validated by > just a single schema. This would be helpful. ...or some way to easily make really bad failures non-fatal. Then I can maybe just diff the results before my patch and after and that'll give me a hint of what I've fixed / made worse. > Probably is. There are cases where a new schema breaks another file's > example. If someone has a gcc node in another example for example. At this point I'm going to say that we're better off than we were, but I'll try to keep this in mind for future patches. -Doug