Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S944591AbcJSRU2 (ORCPT ); Wed, 19 Oct 2016 13:20:28 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:57058 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932794AbcJSRUY (ORCPT ); Wed, 19 Oct 2016 13:20:24 -0400 DMARC-Filter: OpenDMARC Filter v1.3.1 smtp.codeaurora.org 0473261AB2 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=pass smtp.mailfrom=vivek.gautam@codeaurora.org MIME-Version: 1.0 In-Reply-To: <3ecf01cc-b9b1-046e-57b8-2bb855b9ac5d@codeaurora.org> References: <1476800897-19898-1-git-send-email-vivek.gautam@codeaurora.org> <1476800897-19898-2-git-send-email-vivek.gautam@codeaurora.org> <3ecf01cc-b9b1-046e-57b8-2bb855b9ac5d@codeaurora.org> From: Vivek Gautam Date: Wed, 19 Oct 2016 22:50:15 +0530 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 01/10] phy: qcom-ufs: remove failure when rx/tx_iface_clk are absent To: Stephen Boyd Cc: kishon , jejb@linux.vnet.ibm.com, vinholikatti@gmail.com, martin.petersen@oracle.com, "linux-kernel@vger.kernel.org" , subhashj@codeaurora.org, linux-scsi@vger.kernel.org, linux-arm-msm@vger.kernel.org, Yaniv Gardi Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1143 Lines: 34 Hi, On Wed, Oct 19, 2016 at 2:48 AM, Stephen Boyd wrote: > On 10/18/2016 07:28 AM, Vivek Gautam wrote: >> From: Yaniv Gardi >> >> Since in future UFS Phy's the tx_iface_clk and rx_iface_clk >> are no longer exist, we should not fail when their initialization >> fail, but rather just report with debug message. >> >> Signed-off-by: Yaniv Gardi >> Signed-off-by: Vivek Gautam >> --- > > Shouldn't we have a different compatible string on future UFS phys so > that we know which number of clks and what clks are required? That's how > we typically handle clk configurations changing. Making them optional > should really only be needed when they're really optional, i.e. things > will work fine if they're there or not. Correct. It makes sense to have different compatible strings for different versions. I will gather more information about previous versions that required this clock, and update as suggested. Regards Vivek -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project