Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936528AbcJRVTC (ORCPT ); Tue, 18 Oct 2016 17:19:02 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:58686 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932872AbcJRVSy (ORCPT ); Tue, 18 Oct 2016 17:18:54 -0400 DMARC-Filter: OpenDMARC Filter v1.3.1 smtp.codeaurora.org DD9C361849 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=sboyd@codeaurora.org Subject: Re: [PATCH v2 01/10] phy: qcom-ufs: remove failure when rx/tx_iface_clk are absent To: Vivek Gautam , kishon@ti.com, jejb@linux.vnet.ibm.com, vinholikatti@gmail.com, martin.petersen@oracle.com, linux-kernel@vger.kernel.org References: <1476800897-19898-1-git-send-email-vivek.gautam@codeaurora.org> <1476800897-19898-2-git-send-email-vivek.gautam@codeaurora.org> Cc: subhashj@codeaurora.org, linux-scsi@vger.kernel.org, linux-arm-msm@vger.kernel.org, Yaniv Gardi From: Stephen Boyd Message-ID: <3ecf01cc-b9b1-046e-57b8-2bb855b9ac5d@codeaurora.org> Date: Tue, 18 Oct 2016 14:18:52 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <1476800897-19898-2-git-send-email-vivek.gautam@codeaurora.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 830 Lines: 20 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. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project