Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp1989820imm; Wed, 16 May 2018 06:18:08 -0700 (PDT) X-Google-Smtp-Source: AB8JxZrqFxaHIS2rLJjIoPvQ3Y0pbCVSaHV2XbWulYCgntJYMRSXwZbrfm3Qc00VpE1xyIb3jefj X-Received: by 2002:a17:902:d681:: with SMTP id v1-v6mr953494ply.16.1526476688932; Wed, 16 May 2018 06:18:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526476688; cv=none; d=google.com; s=arc-20160816; b=TrF1JzSme1TxfXAqPrCO5XrXZ8wM2GOFVmsrKXdCw+3uEjmtQ7GvfZpvGMdIRFGpXj KJAZyPGIISJtByjAoB+v+lDHTKwSiizr6oPjbHVC5nBGSHasmbEMmAc3nDWRwB8nSC4x CCdmTp4pNCzrRqmt3q+XaCQCK/RcyPh74/ctKW8ovThxfazcCTQcxLVcHdmooXxhUpy2 aRsUXSVAcI2J253yvpTg3loIRbElOw6IksN+HNS7suXovEvXOmz35//A86KdJBCqtbVX cw1AXbwgG4vxEjPYOpFpvmZZL9UY8jK4rYxhMagG+02ge5FTrk9P1i+Ye5j3zWkeNXwN qbOw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:references:in-reply-to:mime-version :dkim-signature:arc-authentication-results; bh=2WmYft9NluXuEJ1imAOjq6v9BF5y5iakjy+T9IuKZoM=; b=fTEVlg9M13regRwW9tVWUTqJPIvDIVsoW0aETxR8sFz0B+ugvrnL1JU1txnhEY4n+O wi9rDYRt8N1rTOaBgdRag1Y2HENaJ5qpBtUAn1Jsruq9f+iEij4O4KeN1n1aIU+YNqU6 zkF/f4VtPXmgWIANCt11mp9DByCqTB0jxNuo+4J1XM7sH+leQXYKlf6vafO9ezJGGuIs aNaLZj0W1bT/IRtfWknUuyME7LM2EWjhqFqQjWNGXMimlR2KGz4p2R4Mp1YFMbHw5mZ0 vPriy6uurZVDjQvv32cIhg6njq9HUaOWm1K3lQmGNhBg7ZFagAZvb0QYW8HrxWC51V4j 49sQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=S7LbGWJ2; 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 i4-v6si2076551pgq.405.2018.05.16.06.17.54; Wed, 16 May 2018 06:18:08 -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=S7LbGWJ2; 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 S1752585AbeEPNQj (ORCPT + 99 others); Wed, 16 May 2018 09:16:39 -0400 Received: from mail.kernel.org ([198.145.29.99]:51276 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751389AbeEPNQg (ORCPT ); Wed, 16 May 2018 09:16:36 -0400 Received: from mail-qt0-f176.google.com (mail-qt0-f176.google.com [209.85.216.176]) (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 E813520863; Wed, 16 May 2018 13:16:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1526476596; bh=Um835TNWl1Fmer8J6EqkMmCVv9DopvUf1G4VJyu7F58=; h=In-Reply-To:References:From:Date:Subject:To:Cc:From; b=S7LbGWJ2p6kcszjK8e0BqVzyh6sqrQnEB9UUkne5w3bQeI6/+jh6GlbIQAS6MjqYp rgD/h1dWsyGdlDF8SoolN8OTgIlblgfbp6O3/dqnMBgUE0YyhtYBAw3fVO/0A263OO bKj6xDwOY8u+mt1cbKFSEQDNiQT8Fy6DecNkDA18= Received: by mail-qt0-f176.google.com with SMTP id m16-v6so898857qtg.13; Wed, 16 May 2018 06:16:35 -0700 (PDT) X-Gm-Message-State: ALKqPwfhOweop5ZntpOi/0xhDLRwACKzc3hNPsULYyv3KrLcvhctIV1E Hdl9IDkC4jdw+8QUIjreYBuy1FQVr/yhLqAYYQ== X-Received: by 2002:aed:3a46:: with SMTP id n64-v6mr898836qte.118.1526476594893; Wed, 16 May 2018 06:16:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.155.2 with HTTP; Wed, 16 May 2018 06:16:14 -0700 (PDT) In-Reply-To: <1699CE87DE933F49876AD744B5DC140FA5AC86@DGGEMM506-MBS.china.huawei.com> References: <20180417140814.38098-1-liwei213@huawei.com> <20180417140814.38098-3-liwei213@huawei.com> <20180424125827.k2dgeu6uon75wzni@rob-hp-laptop> <1699CE87DE933F49876AD744B5DC140FA5AC86@DGGEMM506-MBS.china.huawei.com> From: Rob Herring Date: Wed, 16 May 2018 08:16:14 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: =?UTF-8?B?UmU6IOetlOWkjTogW1BBVENIIHY5IDIvNV0gZHQtYmluZGluZ3M6IHNjc2k6IHVmczogYQ==?= =?UTF-8?B?ZGQgZG9jdW1lbnQgZm9yIGhpc2ktdWZz?= To: "liwei (CM)" Cc: "mark.rutland@arm.com" , "catalin.marinas@arm.com" , "will.deacon@arm.com" , "vinholikatti@gmail.com" , "jejb@linux.vnet.ibm.com" , "martin.petersen@oracle.com" , "khilman@baylibre.com" , "arnd@arndb.de" , "gregory.clement@free-electrons.com" , "thomas.petazzoni@free-electrons.com" , "yamada.masahiro@socionext.com" , "riku.voipio@linaro.org" , "treding@nvidia.com" , "krzk@kernel.org" , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-scsi@vger.kernel.org" , zangleigang , Gengjianfeng , "guodong.xu@linaro.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 24, 2018 at 8:54 AM, liwei (CM) wrote: > Hi, Rob > > Thanks for your patience. > > Hi, Arnd > > From Rob's suggestion, we have to list the properties node in ufs-hisi.tx= t bingings even if documented in the common binding. > > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: Rob Herring [mailto:robh@kernel.org] > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2018=E5=B9=B44=E6=9C=8824=E6=97=A5 = 20:58 > =E6=94=B6=E4=BB=B6=E4=BA=BA: liwei (CM) > =E6=8A=84=E9=80=81: mark.rutland@arm.com; catalin.marinas@arm.com; will.d= eacon@arm.com; vinholikatti@gmail.com; jejb@linux.vnet.ibm.com; martin.pete= rsen@oracle.com; khilman@baylibre.com; arnd@arndb.de; gregory.clement@free-= electrons.com; thomas.petazzoni@free-electrons.com; yamada.masahiro@socione= xt.com; riku.voipio@linaro.org; treding@nvidia.com; krzk@kernel.org; device= tree@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-kernel@lists.= infradead.org; linux-scsi@vger.kernel.org; zangleigang; Gengjianfeng; guodo= ng.xu@linaro.org > =E4=B8=BB=E9=A2=98: Re: [PATCH v9 2/5] dt-bindings: scsi: ufs: add docume= nt for hisi-ufs > > On Tue, Apr 17, 2018 at 10:08:11PM +0800, Li Wei wrote: >> add ufs node document for Hisilicon. >> >> Signed-off-by: Li Wei >> --- >> Documentation/devicetree/bindings/ufs/ufs-hisi.txt | 29 +++++++++++++++= +++++++ >> .../devicetree/bindings/ufs/ufshcd-pltfrm.txt | 10 +++++--- >> 2 files changed, 36 insertions(+), 3 deletions(-) >> create mode 100644 Documentation/devicetree/bindings/ufs/ufs-hisi.txt >> >> diff --git a/Documentation/devicetree/bindings/ufs/ufs-hisi.txt b/Docume= ntation/devicetree/bindings/ufs/ufs-hisi.txt >> new file mode 100644 >> index 000000000000..d49ab7d8f31d >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/ufs/ufs-hisi.txt >> @@ -0,0 +1,29 @@ >> +* Hisilicon Universal Flash Storage (UFS) Host Controller >> + >> +UFS nodes are defined to describe on-chip UFS hardware macro. >> +Each UFS Host Controller should have its own node. >> + >> +Required properties: >> +- compatible : compatible list, contains one of the following - >> + "hisilicon,hi3660-ufs", "jedec,ufs= -1.1" for hisi ufs >> + host controller present on Hi36xx = chipset. >> +- reg : should contain UFS register address space & UFS S= YS CTRL register address, >> +- interrupt-parent : interrupt device >> +- interrupts : interrupt number >> +- resets : reset node register, the "arst" corresponds to re= set the APB/AXI bus. > > arst belongs in reset-names. > > OK, I will fix it in next patch; > >> +- reset-names : describe reset node register > > What happened to clocks? You still have to list which ones apply even if > documented in the common binding. > > OK, I will fix it in next patch; > >> + >> +Example: >> + >> + ufs: ufs@ff3b0000 { >> + compatible =3D "hisilicon,hi3660-ufs", "jedec,ufs-1.1"; >> + /* 0: HCI standard */ >> + /* 1: UFS SYS CTRL */ >> + reg =3D <0x0 0xff3b0000 0x0 0x1000>, >> + <0x0 0xff3b1000 0x0 0x1000>; >> + interrupt-parent =3D <&gic>; >> + interrupts =3D ; >> + /* offset: 0x84; bit: 7 */ >> + resets =3D <&crg_rst 0x84 7>; >> + reset-names =3D "arst"; >> + }; >> diff --git a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt b/D= ocumentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt >> index c39dfef76a18..adcfb79f63f5 100644 >> --- a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt >> +++ b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt >> @@ -41,6 +41,8 @@ Optional properties: >> -lanes-per-direction : number of lanes available per direction - either= 1 or 2. >> Note that it is assume same number of lanes is u= sed both >> directions at once. If not specified, default is= 2 lanes per direction. >> +- resets : reset node register, the "rst" corresponds to res= et the whole UFS IP. >> +- reset-names : describe reset node register > > Does your controller have 1 or 2 resets? There's no point in adding this > here if it doesn't apply to your controller. > > There are 2 reset in our soc init, the "rst" corresponds to reset the who= le UFS IP, and " arst " only reset the APB/AXI bus. > Discussed with our soc colleagues that "arst" is assert by default and ne= eds to deassert,but it done in bootloader,so will remove 'arst' in next pat= ch. > > About the 'reset' property=EF=BC=8Cit seems that Arnd Bergmann has differ= ent suggestion=EF=BC=8Che suggested that add 'rst' to ufshcd-pltfrm because= it seems common. > But it looks like only our soc init needs it. What's your opinion? Does i= t still needs add to common bindings? For a single reset, then I'm fine with it being in the common bindings. If there are multiple then it should be in the specific bindings as the reset names are likely different. Rob