Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp180774imm; Wed, 29 Aug 2018 17:45:03 -0700 (PDT) X-Google-Smtp-Source: ANB0VdYjpATHpzJks8NruG8FNBsYTtZb1iK9xYNuQNMe0XixP+Z17ElK2UvFnj9P+I2pxJGpRirP X-Received: by 2002:a17:902:31a4:: with SMTP id x33-v6mr7930968plb.218.1535589903861; Wed, 29 Aug 2018 17:45:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1535589903; cv=none; d=google.com; s=arc-20160816; b=Komb62hs8iJbFRUkHDJW6ZIk5XXCsm87RLkTlbXZI/C/xqTR/jwGIOHL5WS7rhV+nb VYV+N3NiaJRwUPyW1BmGGsWP6Ae/j13mMMxiO4vGZkiVHUTuNP0Ir4IYo/nkkR26vgDp yN36AHlCVvbwB7oKtQnsQz2ZxPQt/hutBs0ypJK5efoIt2TP0/iesQd2Os4QvDtd2N9G jiamKWm866GFMqwEorMwS/HN6XV1zILmlfS8MrIK16kVMddB2bZIIqeOlgo385pMbzEk hoAzJ68JBOwg7IaURx9jYuaFfmddZCgjMJP96cl/5ZlmDtCD+Bt3aE+jf2C8JdARYXos HiVQ== 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 :arc-authentication-results; bh=qp41ButyyOttan1zWYYojD87foeNd+WeoYG2eRnFAJw=; b=uQKTPFt8Njn+lR6MvWhGkGmJI9XqxZuVW6M+iuIcZ/eM5Gv72INiNyIo30WnDLYGge S8aXk6fAtcz5GI/qnz6JXIPbzhlXFC7ZHlZsdQemKkDS58qAfgbmMAqU1s0thBxS5+I/ W9JO8/cjUO/kTzJLcjTOBWTXVNyi0E9QZnOUHgJqDRbMyyqpIpVUnkOj15Jk7zeH//kU XVU6xCYdsCfRfkp0+c15WkfOKosmDLDgVAVXcbY49nXqiVIxRYbQV/3XynlnBIYZ5eai bV26rM48ZWokAB631dWBaMdNE6NDdMoveN4Ur4icfWKSsg4JOXi/rakp5uXGNNdBsjOG GchQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=NnGZzrzH; 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=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g87-v6si5482528pfg.225.2018.08.29.17.44.48; Wed, 29 Aug 2018 17:45:03 -0700 (PDT) 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=@kernel.org header.s=default header.b=NnGZzrzH; 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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727178AbeH3EnL (ORCPT + 99 others); Thu, 30 Aug 2018 00:43:11 -0400 Received: from mail.kernel.org ([198.145.29.99]:48318 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725996AbeH3EnL (ORCPT ); Thu, 30 Aug 2018 00:43:11 -0400 Received: from mail-qk0-f173.google.com (mail-qk0-f173.google.com [209.85.220.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 907B120671; Thu, 30 Aug 2018 00:43:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1535589822; bh=QV1qUjLTkIbnCZc7KpgPp9Y1RE8naddxILOO5lwIOPY=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=NnGZzrzH2F6/VtO4NIRJAGAhxw/x8rEFmdeVgpd0cZh1DUiQdkBO46Hwr7J9z/j0s ocnVhbvkS32/MuYugsE6+toztR8Rocs+OEOBSbNKrSVvnriDw/TX/eo7UevSl2zowC r0BHkAScle7vzmypyEquYDxc/RLhDCaNrCJe/NhU= Received: by mail-qk0-f173.google.com with SMTP id g13-v6so4672918qki.9; Wed, 29 Aug 2018 17:43:42 -0700 (PDT) X-Gm-Message-State: APzg51B+CivQoSpvfTwFB+ynQ4/ciCND5TkLhOXMU4a0sUtd+eOI6Rra rH10vMmnpVG22K3iffUn6XeWhRlBfBzby2m2hw== X-Received: by 2002:a37:f19:: with SMTP id z25-v6mr8985597qkg.147.1535589821768; Wed, 29 Aug 2018 17:43:41 -0700 (PDT) MIME-Version: 1.0 References: <20180827105551.16346-1-vivek.gautam@codeaurora.org> <20180827105551.16346-5-vivek.gautam@codeaurora.org> <20180828203418.GA18366@bogus> In-Reply-To: From: Rob Herring Date: Wed, 29 Aug 2018 19:43:30 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [Patch v15 4/5] dt-bindings: arm-smmu: Add bindings for qcom,smmu-v2 To: Vivek Gautam Cc: Mark Rutland , devicetree@vger.kernel.org, alex.williamson@redhat.com, "Rafael J. Wysocki" , Stephen Boyd , freedreno , "open list:THERMAL" , Will Deacon , "linux-kernel@vger.kernel.org" , Linux IOMMU , linux-arm-msm , Andy Gross , Robin Murphy 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 On Wed, Aug 29, 2018 at 6:23 AM Vivek Gautam wrote: > > On Wed, Aug 29, 2018 at 2:05 PM Vivek Gautam > wrote: > > > > Hi Rob, > > > > > > On 8/29/2018 2:04 AM, Rob Herring wrote: > > > On Mon, Aug 27, 2018 at 04:25:50PM +0530, Vivek Gautam wrote: > > >> Add bindings doc for Qcom's smmu-v2 implementation. > > >> > > >> Signed-off-by: Vivek Gautam > > >> Reviewed-by: Tomasz Figa > > >> Tested-by: Srinivas Kandagatla > > >> --- > > >> > > >> Changes since v14: > > >> - This is a new patch added in v15 after noticing the new > > >> checkpatch warning for separate dt-bindings doc. > > >> - This patch also addresses comments given by Rob and Robin to add > > >> a list of valid values of '' in "qcom,-smmu-v2" > > >> compatible string. > > >> > > >> .../devicetree/bindings/iommu/arm,smmu.txt | 47 ++++++++++++++++++++++ > > >> 1 file changed, 47 insertions(+) > > >> > > >> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt b/Documentation/devicetree/bindings/iommu/arm,smmu.txt > > >> index 8a6ffce12af5..52198a539606 100644 > > >> --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt > > >> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt > > >> @@ -17,10 +17,24 @@ conditions. > > >> "arm,mmu-401" > > >> "arm,mmu-500" > > >> "cavium,smmu-v2" > > >> + "qcom,-smmu-v2", "qcom,smmu-v2" > > > The v2 in the compatible string is kind of redundant unless the SoC has > > > other SMMU types. > > > > sdm845 has smmu-v2, and smmu-500 [1]. > > > > >> > > >> depending on the particular implementation and/or the > > >> version of the architecture implemented. > > >> > > >> + A number of Qcom SoCs use qcom,smmu-v2 version of the IP. > > >> + "qcom,-smmu-v2" represents a soc specific compatible > > >> + string that should be present along with the "qcom,smmu-v2" > > >> + to facilitate SoC specific clocks/power connections and to > > >> + address specific bug fixes. > > >> + '' string in "qcom,-smmu-v2" should be one of the > > >> + following: > > >> + msm8996 - for msm8996 Qcom SoC. > > >> + sdm845 - for sdm845 Qcom Soc. > > > Rather than all this prose, it would be simpler to just add 2 lines with > > > the full compatibles rather than . The thing is not going to > > > work when/if we move bindings to json-schema also. > > > > then we keep adding > > "qcom,msm8996-smmu-v2", "qcom,smmu-v2" > > "qcom,msm8998-smmu-v2", "qcom,smmu-v2" > > "qcom,sdm845-smmu-v2", "qcom,smmu-v2", > > and from [1] > > "qcom,sdm845-smmu-500", "arm,mmu-500", etc. > > for each SoCs? > > How about following diff on top of this patch? > > diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt > b/Documentation/devicetree/bindings/iommu/arm,smmu.txt > index 52198a539606..5e6c04876533 100644 > --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt > +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt > @@ -17,23 +17,18 @@ conditions. > "arm,mmu-401" > "arm,mmu-500" > "cavium,smmu-v2" > - "qcom,-smmu-v2", "qcom,smmu-v2" > + "qcom,smmu-v2" > > depending on the particular implementation and/or the > version of the architecture implemented. > > - A number of Qcom SoCs use qcom,smmu-v2 version of the IP. > - "qcom,-smmu-v2" represents a soc specific compatible > - string that should be present along with the "qcom,smmu-v2" > - to facilitate SoC specific clocks/power connections and to > - address specific bug fixes. > - '' string in "qcom,-smmu-v2" should be one of the > - following: > - msm8996 - for msm8996 Qcom SoC. > - sdm845 - for sdm845 Qcom Soc. > - > - An example string would be - > - "qcom,msm8996-smmu-v2", "qcom,smmu-v2". > + Qcom SoCs using qcom,smmu-v2 must have soc specific > + compatible string attached to "qcom,smmu-v2" to take care > + of SoC specific clocks/power connections and to address > + specific bug fixes. > + Precisely, it should be one of the following: > + "qcom,msm8996-smmu-v2", "qcom,smmu-v2", > + "qcom,sdm845-smmu-v2", "qcom,smmu-v2". We don't need an explanation of why we need specific compatibles in each binding document (though maybe we need a better explanation somewhere). We just need to know what are valid values for compatibles and this includes any combinations. Generally, this is just a list of combinations. The Renesas folks have figured out how to do this and they have lots of SoCs. Yes, it makes for a lot of patches, but they are all mostly 1 liners and are dead simple to review. With QCom, I'm tired of having the same damn discussion with every new binding. Rob