Re: [PATCH v3 04/12] phy: qcom-ufs-14nm: Add new compatible for msm8996 based phy

[Subhash Jadavani <subhashj@codeaurora.org>]

On 2016-11-03 10:07, Vivek Gautam wrote:
> Hi,
> 
> 
> On Tue, Nov 1, 2016 at 2:41 AM, Subhash Jadavani
> <subhashj@codeaurora.org> 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 <vivek.gautam@codeaurora.org>
>>> ---
>>> 
>>> 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 
<subhashj@codeaurora.org>

> 
> 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