Received: by 10.213.65.68 with SMTP id h4csp32168imn; Sat, 24 Mar 2018 12:37:44 -0700 (PDT) X-Google-Smtp-Source: AG47ELswlLZxToKfdcEHfLL2FhwL0U6I6rwmWBqZ2VNNtjMqIJWynCjhWo6KeHPpizYPTS9wKf42 X-Received: by 10.98.156.16 with SMTP id f16mr28183600pfe.180.1521920264140; Sat, 24 Mar 2018 12:37:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521920264; cv=none; d=google.com; s=arc-20160816; b=IpJaGFFu+2rVmHdoxIAfca6BjdEvaE9kJpz1MNprToyEg+9ufqV70nna7nInrvlD8e VLs6i5ZaqAu+Z8O6JGC25pyyy+s+GiGiPZsef7dIZ4RUiu3DpVSCo5eh3Bu3FseyyOWN ToMQmy0oASQkT0+/XWzO+ym4WB+WRldRRJG6tXXurt9+FVbxgSGbUjl3tLK01tZd7r/t +fNOZjRoKkCRhhpUglfJJdMXx8L17Fh3weUri+N2rAppt+eMoJ3gFruzRsdCtCiqkZc/ 8xMwmlOYWMQeUUHPTy+AyEE1rW96dUzMBkfkiJvABabfSR2NKAzVAUYrQlgQfebNNOYL Pzww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:content-transfer-encoding :references:in-reply-to:date:cc:to:from:subject:message-id :arc-authentication-results; bh=TWEpV2Cr7QXPg6XTQti8MRR1vyefKxms6DVPsxeWo+M=; b=xOrJNQ32B9A6tpt+SGD+1KfLlAVNc/3AYq58qRDqIM8DQJOtmsa+PyuigPhB/9dqHe IKSeGYSLaNl0valDGNYc110Kut9qO8yUsejOvzXfQXLbwBj372rIAD735H0w9s3oWWmx a4+Lu0Sm2C4PnD8QzllOmLd2N/4UKnYKAGMl9s0YToCjExEm5MPOXvmP3l85U1Xfz/KS 2eTX9NxVZdS4KhlDMbr6Z+KKKY6MHrvdbU9o8pu72/VAXj+YA77V1URcEC/WiK6mA0a9 Volqp3GpF2tMZ0pEfDCeMlBxUituICLuxehY35bPTJcj6GVC2t/46lEHNqwRmVCV9wUl W6KA== ARC-Authentication-Results: i=1; mx.google.com; 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 a8-v6si11600711plz.320.2018.03.24.12.37.29; Sat, 24 Mar 2018 12:37:44 -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; 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 S1752778AbeCXTgj (ORCPT + 99 others); Sat, 24 Mar 2018 15:36:39 -0400 Received: from mailgw01.mediatek.com ([210.61.82.183]:37471 "EHLO mailgw01.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1752633AbeCXTgg (ORCPT ); Sat, 24 Mar 2018 15:36:36 -0400 X-UUID: bcdd74a9d8554f6fb562ba73b13e2407-20180325 Received: from mtkexhb02.mediatek.inc [(172.21.101.103)] by mailgw01.mediatek.com (envelope-from ) (mhqrelay.mediatek.com ESMTP with TLS) with ESMTP id 219865461; Sun, 25 Mar 2018 03:36:30 +0800 Received: from mtkcas08.mediatek.inc (172.21.101.126) by mtkmbs08n1.mediatek.inc (172.21.101.55) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 25 Mar 2018 03:36:28 +0800 Received: from [172.21.77.33] (172.21.77.33) by mtkcas08.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1210.3 via Frontend Transport; Sun, 25 Mar 2018 03:36:28 +0800 Message-ID: <1521920188.31197.13.camel@mtkswgap22> Subject: Re: [PATCH v1 02/16] dt-bindings: rtc: mediatek: add bindings for PMIC RTC From: Sean Wang To: Alexandre Belloni CC: , , , , , , , , , , Date: Sun, 25 Mar 2018 03:36:28 +0800 In-Reply-To: <20180323101505.GF3417@piout.net> References: <5846e8be319c4836808c8127d5bb51b7e999e896.1521794177.git.sean.wang@mediatek.com> <20180323094118.GC3417@piout.net> <20180323101505.GF3417@piout.net> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-TM-AS-Product-Ver: SMEX-12.5.0.5042-8.2.9001-23738.005 X-TM-AS-Result: No-10.615200-8.000000-10 X-TMASE-MatchedRID: +f/wAVSGjugOwH4pD14DsPHkpkyUphL9fjJOgArMOCYXdhT0BAdFzk/3 ZkXeY1OAi7JD4mlosIS761Rb2kt6b2s/tFw6ZTQWuIwLnB3Aqp3ljSRvSGpq3AZbeEWcL03V4MZ M1Q/ZcvBLRkRuoSRiHL+NGXTE0PnNTR46EMdjJlZ05zsoB1UKTkKzuF0egUUDh/BqejSDeoKUFF IrQpGG/SNBXu8ljadXNWPYAkCKHy486+EySo7pCqvXuBj6Dd7xWzrNDQlnopOyBGiU7DpYDgLyt DvV39h+Fz9JmG8jAX9y7IDs8lt2DFr6zeO3/gBbGVyS87Wb4lySw7DTBrivRGr0f41EQsJWo8WM kQWv6iUD0yuKrQIMCD3Al4zalJpFIAcCikR3vq8Hz3XZkW9+htaCETEx0eukQwmILSM7KLKcLom 6J9TVxdnGZsAfI3Af X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--10.615200-8.000000 X-TMASE-Version: SMEX-12.5.0.5042-8.2.9001-23738.005 X-TMASE-POSTMAN: 2-d; X-MTK: N Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2018-03-23 at 11:15 +0100, Alexandre Belloni wrote: > On 23/03/2018 at 10:41:18 +0100, Alexandre Belloni wrote: > > Hi, > > > > On 23/03/2018 at 17:14:59 +0800, sean.wang@mediatek.com wrote: > > > From: Sean Wang > > > > > > Add device-tree binding for MediaTek PMIC based RTC. > > > > > > Signed-off-by: Sean Wang > > > --- > > > .../devicetree/bindings/rtc/rtc-mt6397.txt | 39 ++++++++++++++++++++++ > > > 1 file changed, 39 insertions(+) > > > create mode 100644 Documentation/devicetree/bindings/rtc/rtc-mt6397.txt > > > > > > diff --git a/Documentation/devicetree/bindings/rtc/rtc-mt6397.txt b/Documentation/devicetree/bindings/rtc/rtc-mt6397.txt > > > new file mode 100644 > > > index 0000000..83ff6be > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/rtc/rtc-mt6397.txt > > > @@ -0,0 +1,39 @@ > > > +Device-Tree bindings for MediaTek PMIC based RTC > > > + > > > +MediaTek PMIC based RTC is an independent function of MediaTek PMIC which > > > +is working as a multi-function device (MFD). And the RTC can be configured and > > > +set up via PMIC wrapper bus. Which is also common resource shared among the > > > +other functions present on the PMIC. > > > + > > > +For MediaTek PMIC wrapper bus bindings, see: > > > +Documentation/devicetree/bindings/soc/mediatek/pwrap.txt > > > + > > > +Required parent node: > > > +- pmic > > > + For MediaTek PMIC MFD bindings, see: > > > + Documentation/devicetree/bindings/mfd/mt6397.txt > > > + > > > +Required properties: > > > +- compatible: Should be one of follows > > > + "mediatek,mt6323-rtc": for MT6323 PMIC > > > + "mediatek,mt6397-rtc": for MT6397 PMIC > > > + > > > +Optional child node: > > > +- power-off > > > + For Power-Off Device for MediaTek PMIC RTC bindings, see: > > > + Documentation/devicetree/bindings/power/reset/mt6397-rtc-poweroff.txt > > > + > > > +Example: > > > + > > > + pmic { > > > + compatible = "mediatek,mt6323"; > > > + > > > + ... > > > + rtc { > > > + compatible = "mediatek,mt6323-rtc"; > > > + > > > + power-off { > > > + compatible = "mediatek,mt6323-rtc-poweroff"; > > > + }; > > > > I'm pretty sure the whole point of mfd is to avoid having the poweroff > > controller under the rtc > > > > BTW, I think it is enough to have that documented in only one file (the > MFD one is enough) > just reply both replies in the same mail 1.) the power-off device is a part of rtc, use the same registers rtc has and thus it is put as child nodes under the node rtc to reflect the reality of characteristics the rtc has. Or am I wrong for a certain aspect in these opinions? 2) the other sub-functions for the same pmic already created its own dt-binding document belonged to its corresponding subsystem. Don't we really want to follow it them all? > > > > -- > > Alexandre Belloni, Bootlin (formerly Free Electrons) > > Embedded Linux and Kernel engineering > > https://bootlin.com >