linux-kernel - Re: [PATCH v4 2/3] arm64: dts: qcom: sar2130p: add support for SAR2130P

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: <8de99bbd-3abe-4ffa-9395-84b81d610875@quicinc.com>
Date: Wed, 27 Nov 2024 21:12:42 +0530
From: Krishna Kurapati <quic_kriskura@...cinc.com>
To: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
CC: Bjorn Andersson <andersson@...nel.org>, <linux-arm-msm@...r.kernel.org>,
        <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        Conor Dooley
	<conor+dt@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Rob Herring
	<robh@...nel.org>, Konrad Dybcio <konradybcio@...nel.org>
Subject: Re: [PATCH v4 2/3] arm64: dts: qcom: sar2130p: add support for
 SAR2130P



On 11/27/2024 7:32 PM, Dmitry Baryshkov wrote:
> On Tue, Nov 26, 2024 at 11:32:59PM +0530, Krishna Kurapati wrote:
>>
>>
>> On 11/2/2024 8:33 AM, Dmitry Baryshkov wrote:
>>> Add DT file for the Qualcomm SAR2130P platform.
>>>
>>> Co-developed-by: Konrad Dybcio <konrad.dybcio@...aro.org>
>>> Signed-off-by: Konrad Dybcio <konrad.dybcio@...aro.org>
>>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
>>> ---
>>>    arch/arm64/boot/dts/qcom/sar2130p.dtsi | 3123 ++++++++++++++++++++++++++++++++
>>>    1 file changed, 3123 insertions(+)
>>>
>>
>> [...]
>>
>>> +		usb_dp_qmpphy: phy@...8000 {
>>> +			compatible = "qcom,sar2130p-qmp-usb3-dp-phy";
>>> +			reg = <0x0 0x088e8000 0x0 0x3000>;
>>> +
>>> +			clocks = <&gcc GCC_USB3_PRIM_PHY_AUX_CLK>,
>>> +				 <&rpmhcc RPMH_CXO_CLK>,
>>> +				 <&gcc GCC_USB3_PRIM_PHY_COM_AUX_CLK>,
>>> +				 <&gcc GCC_USB3_PRIM_PHY_PIPE_CLK>;
>>> +			clock-names = "aux", "ref", "com_aux", "usb3_pipe";
>>> +
>>> +			power-domains = <&gcc USB3_PHY_GDSC>;
>>> +
>>> +			resets = <&gcc GCC_USB3_PHY_PRIM_BCR>,
>>> +				 <&gcc GCC_USB3_DP_PHY_PRIM_BCR>;
>>> +			reset-names = "phy", "common";
>>> +
>>> +			#clock-cells = <1>;
>>> +			#phy-cells = <1>;
>>> +
>>> +			orientation-switch;
>>> +
>>> +			status = "disabled";
>>> +
>>
>> Hi Dmitry,
>>
>>   Sorry for asking this question after code got merged. I forgot about asking
>> this last time when I commented on your patch and provided the HS Phy IRQ
>> value.
>>
>>   In SAR2130P, I remember that the lane orientation is reversed. As in on
>> normal targets, if the orientatin GPIO reads "0" it means LANE_A but on
>> SAR2130 it means LANE_B. Can you confirm if superspeed was tested only in
>> one orientation only. >
> Thanks for the notice. I don't remember if I had USB3 or just USB2

Basically during "qmp_combo_com_init()" call, we program the orientation 
based on gpio output from ucsi:

	val = SW_PORTSELECT_MUX;
	if (qmp->orientation == TYPEC_ORIENTATION_REVERSE)
		val |= SW_PORTSELECT_VAL;
	writel(val, com + QPHY_V3_DP_COM_TYPEC_CTRL);

  On SAR2130P, the above logic is reverse. If the cable is set in normal 
orientation, the SW_PORTSELECT_VAL must be set. You can compare the 
result on some mobile target like SM8550/SM8650 vs SAR2130 to confirm 
the observation.

> connected to the USB-C connector. I will take a look and report
> afterwards, but it might take some time.
> 

  No worries. Just wanted to bring this to your notice. On day-1 of 
bring-up, I did struggle for some time to figure out that the CC 
orientation is flipped since every cable flip was working in High Speed 
as lanes were programmed reverse all the time. I didn't want you to hit 
that issue for when the orientation switch is actually enabled.

  On a side note, there were some issues found in qmp combo phy during 
stress testing which are specific to SAR2130P. I can try and fix them up 
after you confirm the above test results now that the target is actually 
present on upstream.

Regards,
Krishna,