linux-kernel - Re: [PATCH v7 3/3] arm64: dts: qcom: sc8280xp-blackrock: dt definition for WDK2023

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: <dd5bad7b-d062-4028-b78a-3888dec4f934@oldschoolsolutions.biz>
Date: Tue, 5 Nov 2024 20:27:19 +0100
From: Jens Glathe <jens.glathe@...schoolsolutions.biz>
To: Krishna Kurapati <quic_kriskura@...cinc.com>,
 Bjorn Andersson <andersson@...nel.org>,
 Konrad Dybcio <konradybcio@...nel.org>
Cc: linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, Merck Hung <merckhung@...il.com>,
 Kalle Valo <kvalo@...nel.org>, Conor Dooley <conor+dt@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Rob Herring <robh@...nel.org>,
 xlazom00@...il.com
Subject: Re: [PATCH v7 3/3] arm64: dts: qcom: sc8280xp-blackrock: dt
 definition for WDK2023

On 04.11.24 05:31, Krishna Kurapati wrote:
>
>
> On 11/1/2024 11:56 PM, Jens Glathe via B4 Relay wrote:
>> From: Jens Glathe <jens.glathe@...schoolsolutions.biz>
>>
>> Device tree for the Microsoft Windows Dev Kit 2023. This work
>> is based on the initial work of Merck Hung <merckhung@...il.com>.
>>
>> Original work:
>> https://github.com/merckhung/linux_ms_dev_kit/blob/ms-dev-kit-2023-v6.3.0/arch/arm64/boot/dts/qcom/sc8280xp-microsoft-dev-kit-2023.dts
>>
>> The Windows Dev Kit 2023 is a nice little desktop based on sc8280xp.
>> Link: https://learn.microsoft.com/en-us/windows/arm/dev-kit/
>>
>> Supported features:
>> - USB type-c and type-a ports
>> - minidp connector
>> - built-in r8152 Ethernet adapter
>> - PCIe devices
>> - nvme
>> - ath11k WiFi (WCN6855)
>> - WCN6855 Bluetooth
>> - A690 GPU
>> - ADSP and CDSP
>> - GPIO keys
>> - Audio definition (works via USB)
>>
>> Signed-off-by: Jens Glathe <jens.glathe@...schoolsolutions.biz>
>> ---
>
> [...]
>
>> +&usb_2 {
>> +    pinctrl-0 = <&usb2_en_state>;
>> +    pinctrl-names = "default";
>> +
>
> On the blackrock platform, for this controller, are there all 4 ports
> given out for use or only one ?
>
> Because if all 4 are there, you might need to give all 4 pinctrls (one
> for each TS3USB221A mux select) here for usb_2 node. If only one port
> is given out for use on the platform, then only one phy (of the 4
> activated below) needs to be marked as active.
>
> In my case, in [1] on the ADP platform, I marked them as always on for
> all gpios on multiport controller since driver had no support added yet.
>
> [1]:
> https://lore.kernel.org/all/20240707085624.3411961-1-quic_kriskura@quicinc.com/
>
Hi Krishna,

thank you for the hints. Unfortunately, I don't have any schematics for
the box. But I tested out activation combinations for all the
usb_2_hsphy and usb_2_qmpphy listed. All of these are also listed in the
usb_2 node in sc8280xp.dtsi. And they all need to be activated to get
the whole usb_2 node up. Leaving out one lets the whole node vanish.
Maybe it is possible to define fewer phys in the usb_2_dwc3 node, I
don't know. The definition as it is now appears to be a safe bet.
What I noticed in the tests was that the pinctrl usb2_en_state had no
effect here. Although, it apparently was required when it was introduced
[1] by Merck Hung and xlazom00@...il.com. Therefore I am hesitant to
remove it. Also, there may be a hint that it is the enable pin of a hub:

$lsusb -tv
[...]
/:  Bus 005.Port 001: Dev 001, Class=root_hub, Driver=xhci-hcd/4p, 480M
     ID 1d6b:0002 Linux Foundation 2.0 root hub
     |__ Port 001: Dev 002, If 0, Class=Hub, Driver=hub/4p, 480M
         ID 045e:0c5f Microsoft Corp.
/:  Bus 006.Port 001: Dev 001, Class=root_hub, Driver=xhci-hcd/2p, 10000M
     ID 1d6b:0003 Linux Foundation 3.0 root hub
     |__ Port 001: Dev 002, If 0, Class=Hub, Driver=hub/4p, 10000M
         ID 045e:0c60 Microsoft Corp.
         |__ Port 001: Dev 003, If 0, Class=Vendor Specific Class,
Driver=r8152, 5000M
             ID 045e:0c5e Microsoft Corp.

For the IDs 045e:0c5e..045e:c60 there isnot much info, only that its
usually a 10/100/1000 r8152 ethernet adapter, and a USB3.2 /USB2.1 4
port hub. How this is wired, though, no idea. In the face of this I
would suggest to keep the definition as it is now.

[1]:
https://github.com/linux-surface/surface-pro-x/issues/43#issuecomment-1536848253

>> +    status = "okay";
>> +};
>> +
>> +&usb_2_hsphy0 {
>> +    vdda-pll-supply = <&vreg_l1b>;
>> +    vdda18-supply = <&vreg_l1c>;
>> +    vdda33-supply = <&vreg_l7d>;
>> +
>> +    status = "okay";
>> +};
>> +
>> +&usb_2_hsphy1 {
>> +    vdda-pll-supply = <&vreg_l8d>;
>> +    vdda18-supply = <&vreg_l1c>;
>> +    vdda33-supply = <&vreg_l7d>;
>> +
>> +    status = "okay";
>> +};
>> +
>> +&usb_2_hsphy2 {
>> +    vdda-pll-supply = <&vreg_l10d>;
>> +    vdda18-supply = <&vreg_l8c>;
>> +    vdda33-supply = <&vreg_l2d>;
>> +
>> +    status = "okay";
>> +};
>> +
>> +&usb_2_hsphy3 {
>> +    vdda-pll-supply = <&vreg_l10d>;
>> +    vdda18-supply = <&vreg_l8c>;
>> +    vdda33-supply = <&vreg_l2d>;
>> +
>> +    status = "okay";
>> +};
>> +
>> +&usb_2_qmpphy0 {
>> +    vdda-phy-supply = <&vreg_l1b>;
>> +    vdda-pll-supply = <&vreg_l4d>;
>> +
>> +    status = "okay";
>> +};
>> +
>> +&usb_2_qmpphy1 {
>> +    vdda-phy-supply = <&vreg_l8d>;
>> +    vdda-pll-supply = <&vreg_l4d>;
>> +
>> +    status = "okay";
>> +};
>> +
>
> [...]
>
>> +    usb2_en_state: usb2-en-state {
>> +        /* TS3USB221A USB2.0 mux select */
>> +        pins = "gpio24";
>> +        function = "gpio";
>> +        drive-strength = <2>;
>> +        bias-disable;
>> +        output-low;
>> +    };
>> +
>
> Regards,
> Krishna,