From mboxrd@z Thu Jan 1 00:00:00 1970 From: Subhash Jadavani Subject: Re: [PATCH v3 04/12] phy: qcom-ufs-14nm: Add new compatible for msm8996 based phy Date: Thu, 03 Nov 2016 23:09:30 -0700 Message-ID: <50d4ecdbe4a5ef3d2251c11f2bab84ca@codeaurora.org> References: <1477772534-14170-1-git-send-email-vivek.gautam@codeaurora.org> <1477772534-14170-5-git-send-email-vivek.gautam@codeaurora.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: linux-scsi-owner@vger.kernel.org To: Vivek Gautam Cc: kishon , jejb@linux.vnet.ibm.com, Vinayak Holikatti , "Martin K. Petersen" , Stephen Boyd , Yaniv Gardi , linux-scsi@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-scsi-owner@vger.kernel.org List-Id: linux-arm-msm@vger.kernel.org On 2016-11-03 10:07, Vivek Gautam wrote: > Hi, > > > On Tue, Nov 1, 2016 at 2:41 AM, Subhash Jadavani > wrote: >> On 2016-10-29 13:22, Vivek Gautam wrote: >>> >>> Add a new compatible string for 14nm ufs phy present on msm8996 >>> chipset. This phy is bit different from the legacy 14nm ufs phy >>> in terms of the clocks that are needed to be handled in the driver. >>> >>> Signed-off-by: Vivek Gautam >>> --- >>> >>> New patch in v3 of this cleanup series. >>> >>> Documentation/devicetree/bindings/ufs/ufs-qcom.txt | 7 +++++-- >>> drivers/phy/phy-qcom-ufs-qmp-14nm.c | 1 + >>> 2 files changed, 6 insertions(+), 2 deletions(-) >>> >>> diff --git a/Documentation/devicetree/bindings/ufs/ufs-qcom.txt >>> b/Documentation/devicetree/bindings/ufs/ufs-qcom.txt >>> index 070baf4..b6b5130 100644 >>> --- a/Documentation/devicetree/bindings/ufs/ufs-qcom.txt >>> +++ b/Documentation/devicetree/bindings/ufs/ufs-qcom.txt >>> @@ -7,8 +7,11 @@ To bind UFS PHY with UFS host controller, the >>> controller node should >>> contain a phandle reference to UFS PHY node. >>> >>> Required properties: >>> -- compatible : compatible list, contains >>> "qcom,ufs-phy-qmp-20nm" >>> - or "qcom,ufs-phy-qmp-14nm" according to the >>> relevant >>> phy in use. >>> +- compatible : compatible list, contains one of the following >>> - >>> + "qcom,ufs-phy-qmp-20nm" for 20nm ufs phy, >>> + "qcom,ufs-phy-qmp-14nm" for legacy 14nm ufs >>> phy, >>> + "qcom,msm8996-ufs-phy-qmp-14nm" for 14nm ufs >>> phy >>> + present on MSM8996 chipset. >> >> For future chipsets (after MSM8996), we have to use this same >> compatible >> strings? If yes, "msm8996" in compatible string name may cause >> confusions? >> may be we should start following v1/v2/... terminologies for this? >> something like "qcom,ufs-phy-qmp-v2" to start with? > > Are we trying to complement the actual IP hardware versioning with this > ? > Isn't it possible that we will end up using v2 for more than a couple > of > actual IP hardware versions ? > > I have seen cases wherein the IP versions are preceded by the > SOC names, the IPs appeared first in. And if the same IP is used in > subsequent SOCs, we use same compatible string. This, rather, > makes things easier to comprehend - it's the same IP that was > used on older SoC. Ok, if this is the standard practice across the board then we should be fine with this. You may add my Reviewed-by: Subhash Jadavani > > I am fine with adding versions to the compatible string as well. > But like i asked earlier - are we just creating versions for our > own understanding, or are we also complementing the actual > IP hardware versions ? > > > Thanks > Vivek -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project