linux-kernel - Re: [v1 1/3] dt-bindings: msm/dsi: Add yaml schema for 7nm DSI PHY

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a453734a-ab1f-bf35-9272-0b94c713f05b@marek.ca>
Date:   Thu, 17 Jun 2021 11:07:07 -0400
From:   Jonathan Marek <jonathan@...ek.ca>
To:     rajeevny@...eaurora.org, Rob Herring <robh@...nel.org>,
        robh+dt@...nel.org
Cc:     dri-devel@...ts.freedesktop.org, linux-arm-msm@...r.kernel.org,
        freedreno@...ts.freedesktop.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, sean@...rly.run, robdclark@...il.com,
        abhinavk@...eaurora.org, kalyan_t@...eaurora.org,
        mkrishn@...eaurora.org
Subject: Re: [v1 1/3] dt-bindings: msm/dsi: Add yaml schema for 7nm DSI PHY

On 6/16/21 1:50 AM, rajeevny@...eaurora.org wrote:
> On 03-06-2021 01:32, rajeevny@...eaurora.org wrote:
>> On 02-06-2021 02:28, Rob Herring wrote:
>>> On Mon, May 31, 2021 at 07:03:53PM +0530, Rajeev Nandan wrote:
>>
>>>> +
>>>> +properties:
>>>> +  compatible:
>>>> +    oneOf:
>>>> +      - const: qcom,dsi-phy-7nm
>>>
>>> When would one use this?
>> This is for SM8250.
>>
>>>
>>>> +      - const: qcom,dsi-phy-7nm-7280
>>>> +      - const: qcom,dsi-phy-7nm-8150
>>>
>>> These don't look like full SoC names (sm8150?) and it's
>>> <vendor>,<soc>-<block>.
>>
>> Thanks, Rob, for the review.
>>
>> I just took the `compatible` property currently used in the DSI PHY 
>> driver
>> (drivers/gpu/drm/msm/dsi/phy/dsi_phy.c), and added a new entry for 
>> sc7280.
>> A similar pattern of `compatible` names are used in other variants of the
>> DSI PHY driver e.g. qcom,qcom,dsi-phy-10nm-8998, qcom,dsi-phy-14nm-660 
>> etc.
>>
>> The existing compatible names "qcom,dsi-phy-7nm-8150" (SoC at the end) 
>> make
>> some sense, if we look at the organization of the dsi phy driver code.
>> I am new to this and don't know the reason behind the current code
>> organization and this naming.
>>
>> Yes, I agree with you, we should use full SoC names. Adding
>> the SoC name at the end does not feel very convincing, so I will 
>> change this
>> to the suggested format e.g. "qcom,sm8250-dsi-phy-7nm", and will 
>> rename the
>> occurrences in the driver and device tree accordingly.
>> Do I need to make changes for 10nm, 14nm, 20nm, and 28nm DSI PHY too?
>> Bindings doc for these PHYs recently got merged to msm-next [1]
>>
>>
>> [1]
>> https://gitlab.freedesktop.org/drm/msm/-/commit/8fc939e72ff80116c090aaf03952253a124d2a8e 
>>
>>
> 
> Hi Rob,
> 
> I missed adding "robh+dt@...nel.org" earlier in this thread.
> 
> Please check my response to your review comments. Regarding your 
> suggestion to use <vendor>,<soc>-<block> format for compatible property, 
> should I also upload a new patch to make changes in 10nm, 14nm, 20nm, 
> and 28nm DSI PHY DT bindings?
> 
> Thanks,
> Rajeev
> 

Hi,

I missed this and ended up sending a similar patch a week later (as part 
of my cphy series, because I needed it to add a "phy-type" property).

"qcom,dsi-phy-7nm" and "qcom,dsi-phy-7nm-8150" aren't new compatibles, 
they were previously documented in the .txt bindings, which are getting 
removed, but the new .yaml bindings didn't include them. Documenting 
them is just a fixup to that patch [1] which is already R-B'd by RobH 
(and has similar compatibles such as "qcom,dsi-phy-10nm" and 
"qcom,dsi-phy-10nm-8998
").

You can use a different/better naming scheme for sc7280, but changing 
the others has nothing to do with adding support for sc7280.

[1] 
https://gitlab.freedesktop.org/drm/msm/-/commit/8fc939e72ff80116c090aaf03952253a124d2a8e