linux-kernel - Re: [PATCH v2] dt-bindings: phy: qcom,usb-snps-femto-v2: Add bindings for QCS9100

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] [day] [month] [year] [list]

Message-ID: <108d2cf4-2b17-4ce1-80aa-988e36de533d@quicinc.com>
Date: Mon, 29 Jul 2024 17:37:59 +0800
From: "Aiqun Yu (Maria)" <quic_aiquny@...cinc.com>
To: Rob Herring <robh@...nel.org>
CC: Trilok Soni <quic_tsoni@...cinc.com>,
        Tengfei Fan
	<quic_tengfan@...cinc.com>, Vinod Koul <vkoul@...nel.org>,
        "Kishon Vijay
 Abraham I" <kishon@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Wesley Cheng <quic_wcheng@...cinc.com>,
        <linux-arm-msm@...r.kernel.org>, <linux-phy@...ts.infradead.org>,
        <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <kernel@...cinc.com>
Subject: Re: [PATCH v2] dt-bindings: phy: qcom,usb-snps-femto-v2: Add bindings
 for QCS9100



On 7/12/2024 4:03 AM, Rob Herring wrote:
> On Thu, Jul 11, 2024 at 06:05:57PM +0800, Aiqun Yu (Maria) wrote:
>>
>>
>> On 7/11/2024 12:45 AM, Trilok Soni wrote:
>>> On 7/10/2024 9:27 AM, Rob Herring wrote:
>>>> On Tue, Jul 09, 2024 at 08:46:19PM +0800, Tengfei Fan wrote:
>>>>> Document the compatible string for USB phy found in Qualcomm QCS9100
>>>>> SoC.
>>>>> QCS9100 is drived from SA8775p. Currently, both the QCS9100 and SA8775p
>>>>> platform use non-SCMI resource. In the future, the SA8775p platform will
>>>>> move to use SCMI resources and it will have new sa8775p-related device
>>>>> tree. Consequently, introduce "qcom,qcs9100-usb-hs-phy" to describe
>>>>> non-SCMI based USB phy.
>>>>>
>>>>> Signed-off-by: Tengfei Fan <quic_tengfan@...cinc.com>
>>>>> ---
>>>>> Introduce support for the QCS9100 SoC device tree (DTSI) and the
>>>>> QCS9100 RIDE board DTS. The QCS9100 is a variant of the SA8775p.
>>>>> While the QCS9100 platform is still in the early design stage, the
>>>>> QCS9100 RIDE board is identical to the SA8775p RIDE board, except it
>>>>> mounts the QCS9100 SoC instead of the SA8775p SoC.
>>>>>
>>>>> The QCS9100 SoC DTSI is directly renamed from the SA8775p SoC DTSI, and
>>>>> all the compatible strings will be updated from "SA8775p" to "QCS9100".
>>>>> The QCS9100 device tree patches will be pushed after all the device tree
>>>>> bindings and device driver patches are reviewed.
>>>>
>>>> I'm not convinced this is not just pointless churn. Aren't we going to 
>>>> end up with 2 compatible strings for everything? SCMI should just change 
>>>> the providers, but otherwise the consumers are the same. I suppose if 
>>>> clocks are abstracted into power-domains (an abuse IMO) then the 
>>>> bindings change.
>>>>
>>>> Why do we need to support both SCMI and not-SCMI for the same chip?
>>>
>>> IOT SKU of this SOC is using the non-SCMI solution and Auto SKU
>>> of this SOC is using the SCMI based solution due to additional
>>> safety requirements. 
>>
>> More add-on information, IOT SKU which have qcs9100 soc mounted will
>> have firmware releases which support non-scmi solution.
>> And AUTO SKU which mounted with SA8775p will have different firmware
>> releases which support SCMI solution.
> 
> Yes, I understand the difference. My question is why should upstream 
> support that? Normally, I wouldn't notice or care, but the churn of 
> renaming everything makes me notice. Why do the maintainers need to 
> review all these extra changes because QCom couldn't figure out their 
> plans?
> 
> So after you duplicate all the compatible strings, what's next? Changing 
> all the SA8775p bindings which is an ABI break? Presumably, some 
> bindings may not change at all? In that case, you don't need any rename.
> I have no visibility into what's coming next, so please educate me.
> 
> The minimal amount of changes here is you are stuck with the existing 
> identifiers for the non-SCMI SKU. Then you can add a "new SoC" for the 
> SCMI SKU. You might not like the names now, but you picked them and are 

After considering the feedback provided on the subject, We have decided
to keep current SA8775p compatible and ABI compatibility in drivers.
Let's close this session and ignore all the current patches here.
Thank you for your input.
> kind of stuck with them.
> 
> Rob

-- 
Thx and BRs,
Aiqun(Maria) Yu