Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp274817ybv; Thu, 6 Feb 2020 22:48:06 -0800 (PST) X-Google-Smtp-Source: APXvYqx5H2Qt51J3kNWTZzObvxiS6w8WKLAIoIJvTZ7RTQioYeaERkkir8iShORdvj7eEliCcUbm X-Received: by 2002:a9d:730e:: with SMTP id e14mr1517108otk.62.1581058086366; Thu, 06 Feb 2020 22:48:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1581058086; cv=none; d=google.com; s=arc-20160816; b=mi/iVUw9xsJPG/VGtjGJ/sL7wKldJiqyV/0+U9nP6fraUJskMdbXQDMf7CFRhDR3Ex 7z9STmaQE/9d6ycjThvyVUK+KnG5qgy18S1P3TQuZ5l30KhbQv3KeAuOYjUQqRpFyYUN tMy5LGlDLaNA/bLJSY1U5nQf0Hzn9fw2oLTCWKe8RfyRTntmlzVO8NDK0DgiKin5hCxv z4/KQJ4u9pZb7WFBKu5wW3y0hNaidXEKpG8kZuTipQmn35tfzFJbEwIm3Aq+TKQ53asB xcSDm7Dk8g+r2uGBG8Cl9f6S4r6Hp+xTdQCvtNV0oprZd3UkG5xghXmkg2wMbpNiNSpO dH5g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:message-id:references :in-reply-to:subject:cc:to:from:date:content-transfer-encoding :mime-version:dkim-signature; bh=oRZTjl7wX0gMUshuocGpEAyXrjo3f1MY/QRXGnPUZTI=; b=YGo3iVPoTr/tXmIfPY9YbjWTgjv3HEFF0KY1N0pOpiLQ1PUAZk5l0Jp6ZtV7qbklD0 6dFKfY4e8zgW0d7HmezrkoIEV+r7kZvImzYKUAXNvcOSv6iU55XBEpSiEN6B98ZW5iQn M7xjJUUuuL/IWgnC4+ibs9ENQKGOCdBvrgL/IUpoPt97vHwMWat4hgRgFVoaLpvqJO4B IsUROMnuBlOPu21AEZ5g0eQR0kR7mjh6joiYtp3c4/Visf8BCdCR6hwAZVeB0AmFJ0u1 19TGUPBHSE+h64ljuUriyFPgaQaFjqTsJ+b8imOapoJudK9d98rC5xuc5EzhuyWXeQt4 d3ug== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@mg.codeaurora.org header.s=smtp header.b=kVPYNx8e; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t25si3560975oic.183.2020.02.06.22.47.54; Thu, 06 Feb 2020 22:48:06 -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=fail header.i=@mg.codeaurora.org header.s=smtp header.b=kVPYNx8e; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726874AbgBGGqy (ORCPT + 99 others); Fri, 7 Feb 2020 01:46:54 -0500 Received: from mail25.static.mailgun.info ([104.130.122.25]:29208 "EHLO mail25.static.mailgun.info" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726819AbgBGGqx (ORCPT ); Fri, 7 Feb 2020 01:46:53 -0500 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt; s=smtp; t=1581058012; h=Message-ID: References: In-Reply-To: Subject: Cc: To: From: Date: Content-Transfer-Encoding: Content-Type: MIME-Version: Sender; bh=oRZTjl7wX0gMUshuocGpEAyXrjo3f1MY/QRXGnPUZTI=; b=kVPYNx8eYrCY69mZmPpkC8KDYZZNw+jhh2Fggw5+S1kj0i5Ucq3Q2TdcF3MY17JdoPlOIny8 6UIth2mtBRhVoRHkDJHZAhzKiDRm8CYZttEwCq7BBOH6gFoVzYgEpYHLlaG7mq3tW1Vlt/+h q9GDiqi7UMRS5LmMXATpJhlgT5g= X-Mailgun-Sending-Ip: 104.130.122.25 X-Mailgun-Sid: WyI0MWYwYSIsICJsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnIiwgImJlOWU0YSJd Received: from smtp.codeaurora.org (ec2-35-166-182-171.us-west-2.compute.amazonaws.com [35.166.182.171]) by mxa.mailgun.org with ESMTP id 5e3d07d8.7fa318378110-smtp-out-n03; Fri, 07 Feb 2020 06:46:48 -0000 (UTC) Received: by smtp.codeaurora.org (Postfix, from userid 1001) id 4E60BC447A0; Fri, 7 Feb 2020 06:46:47 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-caf-mail-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=2.0 tests=ALL_TRUSTED,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: kgunda) by smtp.codeaurora.org (Postfix) with ESMTPSA id 5FFD8C43383; Fri, 7 Feb 2020 06:46:46 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 07 Feb 2020 12:16:46 +0530 From: kgunda@codeaurora.org To: Rob Herring Cc: Stephen Boyd , Andy Gross , Bjorn Andersson , Lee Jones , Mark Rutland , devicetree@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, rnayak@codeaurora.org, linux-arm-msm-owner@vger.kernel.org Subject: Re: [PATCH V3 1/2] mfd: qcom-spmi-pmic: Convert bindings to .yaml format In-Reply-To: <20200206220638.GA28227@bogus> References: <1580997328-16365-1-git-send-email-kgunda@codeaurora.org> <5e3c63d0.1c69fb81.c2bba.0957@mx.google.com> <20200206220638.GA28227@bogus> Message-ID: <1d7e38197bcaec99dd4e669b5dc8e31c@codeaurora.org> X-Sender: kgunda@codeaurora.org User-Agent: Roundcube Webmail/1.3.9 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020-02-07 03:36, Rob Herring wrote: > On Thu, Feb 06, 2020 at 11:06:55AM -0800, Stephen Boyd wrote: >> Quoting Kiran Gunda (2020-02-06 05:55:26) >> > Convert the bindings from .txt to .yaml format. >> > >> > Signed-off-by: Kiran Gunda >> > --- >> >> Did something change? Is there a cover letter? >> >> > diff --git a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml >> > new file mode 100644 >> > index 0000000..affc169 >> > --- /dev/null >> > +++ b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml >> > @@ -0,0 +1,115 @@ >> > +# SPDX-License-Identifier: GPL-2.0-only >> > +%YAML 1.2 >> > +--- >> > +$id: http://devicetree.org/schemas/bindings/mfd/qcom,spmi-pmic.yaml# >> > +$schema: http://devicetree.org/meta-schemas/core.yaml# >> > + >> > +title: Qualcomm SPMI PMICs multi-function device bindings >> > + >> > +maintainers: >> > + - Lee Jones >> > + - Stephen Boyd >> >> Please change this to sboyd@kernel.org > > Should be the h/w owner, not applier of changes. > Ok.. I will remove it in next post. >> >> > + >> > +description: | >> > + The Qualcomm SPMI series presently includes PM8941, PM8841 and PMA8084 >> > + PMICs. These PMICs use a QPNP scheme through SPMI interface. >> >> This first sentence will need continual updating. Please drop it. >> >> > + QPNP is effectively a partitioning scheme for dividing the SPMI extended >> > + register space up into logical pieces, and set of fixed register >> > + locations/definitions within these regions, with some of these regions >> > + specifically used for interrupt handling. >> > + >> > + The QPNP PMICs are used with the Qualcomm Snapdragon series SoCs, and are >> > + interfaced to the chip via the SPMI (System Power Management Interface) bus. >> > + Support for multiple independent functions are implemented by splitting the >> > + 16-bit SPMI slave address space into 256 smaller fixed-size regions, 256 bytes >> > + each. A function can consume one or more of these fixed-size register regions. >> > + >> > +properties: >> > + compatible: >> > + enum: >> > + - qcom,pm8941 >> > + - qcom,pm8841 >> > + - qcom,pma8084 >> > + - qcom,pm8019 >> > + - qcom,pm8226 >> > + - qcom,pm8110 >> > + - qcom,pma8084 >> > + - qcom,pmi8962 >> > + - qcom,pmd9635 >> > + - qcom,pm8994 >> > + - qcom,pmi8994 >> > + - qcom,pm8916 >> > + - qcom,pm8004 >> > + - qcom,pm8909 >> > + - qcom,pm8950 >> > + - qcom,pmi8950 >> > + - qcom,pm8998 >> > + - qcom,pmi8998 >> > + - qcom,pm8005 >> > + - qcom,spmi-pmic >> >> I think we want qcom,spmi-pmic to be there always. To do that we need >> it >> to look like: >> >> compatible: >> items: >> enum: >> - qcom,pm8941 >> ... >> enum: >> - qcom,spmi-pmic > > Yes, but missing '-' before the enum's. > Will add it in next post >> >> > + >> > + reg: >> > + maxItems: 1 >> > + description: >> > + Specifies the SPMI USID slave address for this device. >> > + For more information see Documentation/devicetree/bindings/spmi/spmi.txt >> > + >> > +patternProperties: >> > + "^.*@[0-9a-f]+$": > > You are going to need to define the specific child nodes with the > schemas for them, but a SPMI bus schema may be useful. > Ok.. I will add it in next post. >> > + type: object >> > + description: >> > + Each child node of SPMI slave id represents a function of the PMIC. In the >> > + example below the rtc device node represents a peripheral of pm8941 >> > + SID = 0. The regulator device node represents a peripheral of pm8941 SID = 1. >> > + >> > + properties: >> > + compatible: >> > + description: >> > + Compatible of the PMIC device. >> > + >> > + interrupts: >> > + maxItems: 2 >> > + description: >> > + Interrupts are specified as a 4-tuple. For more information >> > + see Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.txt >> >> Just make this bindings/spmi/qcom,spmi-pmic-arb.txt so that we don't >> have to worry about it. Why is max items 2? Isn't it 4? Is this >> property >> supposed to be specified at all? >> >> > + >> > + interrupt-names: >> > + description: >> > + Corresponding interrupt name to the interrupts property >> >> Does this need to be specified either? >> >> > + >> > + required: >> > + - compatible >> > + >> > +required: >> > + - compatible >> > + - reg >> > + >> > +examples: >> > + - | >> > + spmi { >> > + compatible = "qcom,spmi-pmic-arb"; >> > + #address-cells = <2>; >> > + #size-cells = <0>; >> > + >> > + pm8941@0 { >> >> pmic@0 >> >> > + compatible = "qcom,pm8941"; >> > + reg = <0x0 0x0>; >> >> Why not include the header file to get the SPMI_USID macro? >> >> > + >> > + rtc { >> > + compatible = "qcom,rtc"; >> > + interrupts = <0x0 0x61 0x1 0x1>; >> > + interrupt-names = "alarm"; >> > + }; >> > + }; >> > + >> > + pm8941@1 { >> >> pmic@1 >> >> > + compatible = "qcom,pm8941"; >> > + reg = <0x1 0x0>; >> > + >> > + regulator { >> > + compatible = "qcom,regulator"; >> > + regulator-name = "8941_boost"; >> > + }; >> > + }; >> > + }; >> > +... >> > -- >> > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, >> > a Linux Foundation Collaborative Project