linux-kernel - Re: [PATCH] arm64: dts: qcom: lemans-evk: Add host mode support for USB1 controller

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: <af3f57a1-8a9d-4b00-8c0b-f6fc6033609e@oss.qualcomm.com>
Date: Tue, 9 Dec 2025 11:33:52 +0530
From: Swati Agarwal <swati.agarwal@....qualcomm.com>
To: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
Cc: linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Krishna Kurapati <krishna.kurapati@....qualcomm.com>,
        andersson@...nel.org, conor+dt@...nel.org, krzk+dt@...nel.org,
        robh@...nel.org, konradybcio@...nel.org,
        Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
Subject: Re: [PATCH] arm64: dts: qcom: lemans-evk: Add host mode support for
 USB1 controller



On 12/8/2025 10:12 PM, Konrad Dybcio wrote:
> On 12/8/25 11:49 AM, Swati Agarwal wrote:
>> Hi,
>>
>>
>> On 12/3/2025 5:17 PM, Konrad Dybcio wrote:
>>> On 12/3/25 12:41 PM, Krishna Kurapati wrote:
>>>>
>>>>
>>>> On 12/3/2025 4:59 PM, Konrad Dybcio wrote:
>>>>> On 12/3/25 3:42 AM, Swati Agarwal wrote:
>>>>>> Enable Host mode support for USB1 controller on EVK Platform.
>>>>>>
>>>>>> For secondary USB Typec port, there is a genesys USB HUB sitting in between
>>>>>> SOC and HD3SS3220 Type-C port controller and SS lines run from the SoC
>>>>>> through the hub to the Port controller. Mark the second USB controller as
>>>>>> host only capable.
>>>>>>
>>>>>> Added HD3SS3220 Type-C port controller along with Type-c connector for
>>>>>> controlling vbus supply.
>>>>>>
>>>>>> Signed-off-by: Swati Agarwal <swati.agarwal@....qualcomm.com>
>>>>>> ---
>>>
>>> [...]
>>>
>>>>>> +                hd3ss3220_47_in_ep: endpoint {
>>>>>
>>>>> How about rename the other one to hd3ss3220_0 and name this one hd3ss322_1?
>>>>> _47 doesn't really tell us anything and may re-appear if there's another
>>>>> instance of this IC on another I2C bus
>>
>> Thanks Konrad and Dmitry for the review.
>> For addressing this renaming for USB0 controller, shall i keep a separate patch and should i address in same DT patch for USB1?>>>
> 
> Separate patch, please
> 
>>>>
>>>> ACK. Can we rename them as "usb-typec_1" and "usb_typec_2" ?
>>>> Krzysztof suggested to use generic names and hence we used "usb-typec" instead of hd3ss3220.
>>>
>>> The generic names rule only applies to node names (text before '@'),
>>> the labels are generally only expected to "make overall sense", I think
>>>
>>>>>> +&usb_1 {
>>>>>> +    dr_mode = "host";
>>>>>
>>>>> The connector states it's a dual-role data and power device. Is there any
>>>>> reason to keep this in host-only mode?
>>>>>
>>>>
>>>> As mentioned in commit text, there is a onboard hub sitting between SoC and the HD3SS3220 port controller. Hence device mode can't be used. This was the reason we left the above port nodes empty since we can't connect them to port nodes of controller.
>>>
>>> It would have helped if I had paid more attention to that message then..
>>>
>>>> Can we mark the connector as host only and remove the empty endpoints ? Would that we sufficient ?
>>>
>>> The connector should definitely be marked host-only, but the endpoints should
>>> still reflect the physical connectivity.
>>>
>>> If I understood your case properly, this is analogous to what &usb2_2_dwc3
>>> does in arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts - see Commit
>>> c02716951e66 ("arm64: dts: qcom: sdm850-lenovo-yoga-c630: add routing for
>>> second USB connector")
>>
>> For adding, onboard hub which is GL3590 in DT, it requires adding SS hub bindings in genesys,gl850g.yaml.
>> My plan is to first submit the binding patch and then follow up with this DT patch on top of it.
> 
> There's already *some* SS hub described in there - what needs updating?
Genesys hub used here has PID 0610 for HS hub and 0625 for SS hub. HS hub PID is available but SS hub PID not available. 

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/usb/genesys,gl850g.yaml?h=next-20251209

Regards,
Swati