Received: by 10.223.185.116 with SMTP id b49csp4556450wrg; Mon, 26 Feb 2018 21:24:41 -0800 (PST) X-Google-Smtp-Source: AH8x224QjnbEmY73cIPgOTZlqz8cQ0xf2COcZagAiGl5gRbeOMP3ArUs+dsSsJdTIZvA8OnhqzfE X-Received: by 10.99.113.94 with SMTP id b30mr10384648pgn.228.1519709080885; Mon, 26 Feb 2018 21:24:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519709080; cv=none; d=google.com; s=arc-20160816; b=ryi6YeZPecUSD/M3b/MZsGDqj2OcQx8QRc9Kkvd/0c419yLdmi7ldBkNg+uoMQPI/v bfXAR/+Bt4GM8EmUZw7e16anZ0AnUfeKhM2FqIVY5VgKHw/jZkXXrYER0131d1a9fuXx AJG9gXkxgHvke9FbPtoKeHZDXXGs3yCUaLeTB4J0PlVMRmCVxvtQgMzu8OL4P5A20d6w qeEw7T9/Ul/IGzfIgKiHgO/sCd+zCL1hliH5GGQk7Rmf9LB0Mt4uOpcc80rvIo5YUtBW RCIQWLi70rsWbda7UYOqd/Ntd/ZSODaqHa+0BP32+8oqSzDHJHk9M0B6Aznz3TAbmU2o R0Kw== 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:dkim-signature :arc-authentication-results; bh=K/ECm9Iw6LQr0fsYnib+bBwmLNiWD1ie9GW2jzop6nU=; b=xg5eTFEVTkxfP5zUPA8gwjLUEUtHVyuzVkNlO+dMRlw7l8CZvk9SK2V96JLqlZ7U3q Kdo20npMsMmA6OyYxwBCTBK1PKqhRuh0icTM8Ez1+vf8zBNDD54Ho/9ATthOC3lArK8p 8ZwlOsG5Xrr27AJ2+4INyDgV+SOgvIdclkjJMIW46S0lPB+MiW5Mqq3/6whlrSpyPAGL 1o1TcDgcQFCFojrKHb/EZiEJQBOvlSjqKn4KnOdQj3W0/k/oIsGZvfK96e17FWbgDQf3 rU3tn3pfC5oYoOtu4QOiPaTv7HMof/gNPQKfXx1wWPlPu08wXAt6xZDbdcHwuikDZk/k FksQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=fYDC2J8d; dkim=pass header.i=@codeaurora.org header.s=default header.b=KW7ws7mE; 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 f69si7920752pfd.211.2018.02.26.21.24.25; Mon, 26 Feb 2018 21:24:40 -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=@codeaurora.org header.s=default header.b=fYDC2J8d; dkim=pass header.i=@codeaurora.org header.s=default header.b=KW7ws7mE; 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 S1752033AbeB0FWP (ORCPT + 99 others); Tue, 27 Feb 2018 00:22:15 -0500 Received: from smtp.codeaurora.org ([198.145.29.96]:38400 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751514AbeB0FWN (ORCPT ); Tue, 27 Feb 2018 00:22:13 -0500 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 7ED9F60115; Tue, 27 Feb 2018 05:22:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1519708932; bh=PAri5ddEN6K/7a9Gw5bOZ+kh0ASz1soi9meI7l19shQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=fYDC2J8d2yX0NBgKjM3fxRTmfpGkeWlJnfdTEVejWhpz3rsnohOS4eulQgDdvLX9K Ek+HYGEbJjAEzV4I99Z1KI5axuJ/umg55VM5Uqj4VXfiT76BWAjXkq2UMloDn9Bo2p lz0IAy/+H2CwanN8yGIoc0YukfCpbbkANsLZDhfQ= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pdx-caf-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=2.0 tests=ALL_TRUSTED,BAYES_00, DKIM_SIGNED,T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.0 Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.codeaurora.org (Postfix) with ESMTP id 9120A60115; Tue, 27 Feb 2018 05:22:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1519708931; bh=PAri5ddEN6K/7a9Gw5bOZ+kh0ASz1soi9meI7l19shQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=KW7ws7mEaFzIM3O8aIoWdW0N5quKPntGoIgRxG8+jk/r684Mw9RdeCiZI3d4FhULQ n+HNcBrI7e8jtBQWrGFTaDCYWKx610CzqMBU/UyFDXhrhKtcvX7/cZc6azi2Ncll09 o0e19Gwsd/mLeyx5ghbHT2Lvcs14nCTxcrp/lDaM= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 27 Feb 2018 13:22:11 +0800 From: cang@codeaurora.org To: Rob Herring Cc: subhashj@codeaurora.org, asutoshd@codeaurora.org, vivek.gautam@codeaurora.org, rnayak@codeaurora.org, vinholikatti@gmail.com, jejb@linux.vnet.ibm.com, martin.petersen@oracle.com, linux-scsi@vger.kernel.org, Gilad Broner , Mark Rutland , Venkat Gopalakrishnan , Noa Rubens , Sujit Reddy Thumma , Maya Erez , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , open list Subject: Re: [PATCH] scsi: ufs-qcom: add number of lanes per direction In-Reply-To: <20180209022915.2kki7avsia2k7tjp@rob-hp-laptop> References: <20180205121021.11012-1-cang@codeaurora.org> <20180209022915.2kki7avsia2k7tjp@rob-hp-laptop> Message-ID: X-Sender: cang@codeaurora.org User-Agent: Roundcube Webmail/1.2.5 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2018-02-09 10:29, Rob Herring wrote: > On Mon, Feb 05, 2018 at 08:02:07PM +0800, Can Guo wrote: >> From: Gilad Broner >> >> Different platforms may have different number of lanes for the UFS >> link. >> Add parameter to device tree specifying how many lanes should be >> configured for the UFS link. And don't print err message for clocks >> that are optional, this leads to unnecessary confusion about failure. >> >> Signed-off-by: Gilad Broner >> Signed-off-by: Subhash Jadavani >> Signed-off-by: Can Guo >> >> diff --git a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt >> b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt >> index 5357919..4cee3f9 100644 >> --- a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt >> +++ b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt >> @@ -31,6 +31,9 @@ Optional properties: >> defined or a value in the array is "0" then it is assumed >> that the frequency is set by the parent clock or a >> fixed rate clock source. >> +- lanes-per-direction: number of lanes available per direction - >> either 1 or 2. >> + Note that it is assume same number of lanes is used both >> directions at once. > > Seems reasonable until someone does not make things symmetrical. We > should design for that case. > You are right, I will make changes like using lanes-tx and lanes-rx for Tx/Rx links for asymmetrial senarios and upload V2 patch >> + If not specified, default is 2 lanes per direction. >> >> Note: If above properties are not defined it can be assumed that the >> supply >> regulators or clocks are always on.