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 for Android: free password hash cracker in your pocket

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

Message-ID: <20240711200354.GA2482879-robh@kernel.org>
Date: Thu, 11 Jul 2024 14:03:54 -0600
From: Rob Herring <robh@...nel.org>
To: "Aiqun Yu (Maria)" <quic_aiquny@...cinc.com>
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 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 
kind of stuck with them.

Rob