From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B80DC3BED42 for ; Mon, 11 May 2026 09:07:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.168.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778490423; cv=none; b=eHonJhQF/b6LaIHVEMTPG+6CUPKhsKEruoSv+ytGEz2s8101GT4/LC8rheRwzBFY8NE58+Q1mjaekzEHGUDeTVtupUVZPXeFpG+SHOXURVFSTH0Vwpj0hqkFD+wXJoKp4pzFPk3AjTL1xNFM/7TDimXReCengGW0TSoN5xfxQuo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778490423; c=relaxed/simple; bh=WxpBNfJwvmWf/X8SMKzFtqemEXiKEhA670DZ/lKOrlQ=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Ywn5o9iwlJzm+VIYYBWRIos1OT2OSKLewXWZC1HJ5fuoJ5+naZPnGlN/kRu7uhOUyPCXnNTicLPUp/fGEGGkQcIDn4g/nwZiy5jP1amsfpY6w85tNtFJiqRP1QX9sE+gOqdW16loE6rZpkYGBuzxgIoo6NHPuzHfCHr47eWipjs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com; spf=pass smtp.mailfrom=oss.qualcomm.com; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b=U/AJSInK; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=WHXJ1NpV; arc=none smtp.client-ip=205.220.168.131 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b="U/AJSInK"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="WHXJ1NpV" Received: from pps.filterd (m0279867.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 64B7go0H671615 for ; Mon, 11 May 2026 09:07:01 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=qcppdkim1; bh= dLsW9rT+luAiGwnM3aLn85XIH1sYKUrmCAMhbyPlETo=; b=U/AJSInKydM44Aas 1TvJzUJnk9VLCdyeofAtdvL6fJEppprBv8LQtbyapn1+QY45cYFGDvnQU6lLnUTm jPfOwbm28dHZ9HnGa06QQbxSGb1Aev2kaIPA9Sda85TEp35pO/Aq7FAPEKF3Q6vr jBLQ0bbLkliUhuk7s2E+BikEKhIxY/m7hkcskPOZmSIcBthbzidXMG8HNLX+vj8w 59k0Yu82SPpJx6fHhbFPcsg5OLwo7Om3x55IeTiymtVmCqBPFwK8innah+1Rbo82 FruJjC7arnUjhdm5ZWpjsHMAxqB05jHgu/GJLRHSl/NJ794EpTafak9pvX2PYgCM G5Hj3g== Received: from mail-vk1-f198.google.com (mail-vk1-f198.google.com [209.85.221.198]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4e2dkskgj1-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Mon, 11 May 2026 09:07:00 +0000 (GMT) Received: by mail-vk1-f198.google.com with SMTP id 71dfb90a1353d-56f6ee26adbso296495e0c.1 for ; Mon, 11 May 2026 02:07:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1778490420; x=1779095220; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=dLsW9rT+luAiGwnM3aLn85XIH1sYKUrmCAMhbyPlETo=; b=WHXJ1NpV35t6f2zaLi4QHgO+BU2+Suo15iynnIfpUe1lzGnyVi5j1Nyz+m9plPCrHe Z/8OYyjrG/hiZ1iH3U46tiDF8P5Z5MBmslthbX7JnUqL21uwBA6IFVPVrkBuWKmeC40K OlywFqyj1+/7lCL0JaZb6ZL/4641fEVYA+RfejhFMfuResshopqEpjpJJoRKYY97OTIn 5KsUp98fMfS4JdG8rbVXRhNOGuqACwPCSqBBTf+9jxTXadF8wevv70TZHM4YnNj5pCOp 4Piwv4phmbiogJ1GzkgdxHgNfAyYKZ74bmCQJ61jIyfYItuV/y2O5NCvclGsgGXFxgn4 PsWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778490420; x=1779095220; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=dLsW9rT+luAiGwnM3aLn85XIH1sYKUrmCAMhbyPlETo=; b=E384yipveEq+K2LJxDG9ZEpp/u26iNa5EQgwRABlYuKCPkR12w0k3AdXuIi5NiRwAH pOTYRrpeuIqMlwVlCmoyb3HdRFzytN+KwjBDjRm4YZ33GUO9l2PrLdymDuwelVoDqCdk FSIddgWV7JJeQ5rOqFmQW+y/WvxVuN0J7mYxcIJLw4X/PfDH9jEuW/Q0bd6QdiS3OX32 091C52G4OD4R554ahZdq3BVzXMqO8freggINMD0gNSDaNxdTbLUrVHF8awCSU9HbzpbO 4EHjaJ2piwab++6wCMX7R19USCQtt7O+ck96PS3WNTbkeXYcB+ES/xD0ki+YLu2iYPEn kfpg== X-Forwarded-Encrypted: i=1; AFNElJ+sUW0+wkCV+3+Xcug/0fetu1kBnk34e2mkrq7P1lIWfm8EcKvxJkIl6DRy0ZS2s/gS9wbDg/Qr9t8RiFQ=@vger.kernel.org X-Gm-Message-State: AOJu0Yy9ny6t10s22J99g+7UvqoI4L44yLj1GWHdzEuZy6XuZMROeQ79 3qzWiCDre0ZrV+276ohYl/lw3lDDehfJ/oDnhImqNECI1qOvhhEXKR3cHm/ZDsnfDXzh7AbvHQQ usnY54pPUZQf42HKkHvy9eiFym9G1qsplspjBfWUcF8nWg2RxM3lsN/7HLmd6jCZWY6U= X-Gm-Gg: Acq92OHf9ZFBwQIkeVtwxv8KA0QKJEsi2pUVVxOepliYNo9zyJPBSsCaKMo+I7WXZh4 4ai4DjdnOti2mqIPPmYGJLDrfQg0y+zeAy5NV4p4NPLqIAeVB5h1liD4UdCH42KC/i9WOMNVwKO im+PC7AbGQxx0w516h1zXDTDk9F2I/yCAp8ooaFnlHhbxvJ2uZPaUNTSMfjEMI+BS5xKjyIyHBH EFm+QacjUUOaZJidz1pOl2Lz0ZrWJurCrjZiojWbKfHvSAbs9ZjMJKai8oLt9r1Re3NSzCwrYI3 zoBzLc18W+F3hHgocJg0Ih/fFDqY5rds2/njpw76H9YhRh0WA6mup3YaRwTMB3S3JOFiMdO8cUV Qk0YDEvIBfX0X3l3bvw6ZvT6a69CRKfI12STIvTGnD9gHMPc+i6e1AXd2UKXvit9PYygbvICerg 89Djg= X-Received: by 2002:a05:6102:31b5:b0:631:437d:be97 with SMTP id ada2fe7eead31-631437dbf33mr1443225137.8.1778490419856; Mon, 11 May 2026 02:06:59 -0700 (PDT) X-Received: by 2002:a05:6102:31b5:b0:631:437d:be97 with SMTP id ada2fe7eead31-631437dbf33mr1443215137.8.1778490419473; Mon, 11 May 2026 02:06:59 -0700 (PDT) Received: from [192.168.119.254] (078088045245.garwolin.vectranet.pl. [78.88.45.245]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-bcd18884a3bsm261121366b.30.2026.05.11.02.06.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 May 2026 02:06:58 -0700 (PDT) Message-ID: <0431f8ff-545b-4533-8bb3-d4f3d2e30032@oss.qualcomm.com> Date: Mon, 11 May 2026 11:06:55 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/2] usb: dwc3: Notify XHCI core of tunneled status To: Thinh Nguyen , Sven Peter Cc: Jack Pham , Konrad Dybcio , Greg Kroah-Hartman , Mathias Nyman , "linux-usb@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "usb4-upstream@oss.qualcomm.com" , Raghavendra Thoorpu , Mika Westerberg References: <20260505-topic-dwc3_tunneling_state-v1-0-4aaa6c3c14cb@oss.qualcomm.com> <20260505-topic-dwc3_tunneling_state-v1-2-4aaa6c3c14cb@oss.qualcomm.com> <1163a026-03b2-4860-a422-eb276920b4aa@oss.qualcomm.com> <670f9a9f-54b9-4109-986e-5071caf1dcaf@oss.qualcomm.com> Content-Language: en-US From: Konrad Dybcio In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwNTExMDEwMCBTYWx0ZWRfXwuRGcK9Wc0yj PKzS8seYGSD1Pfw38gDQ45h3Yq9PSPiyhO5EANm/HE+NrRx9n87hrzjWMobgsZMHEZ1f/DCh//J Cj+MkakGbG5V9ZXawQboyPQVBiFZ707pVZMYxcevhqc4ScG/iZ79XWHjMqo0M0N41gUsne8zLUP LJ57iOa23YKVzEpaKv7vdaUPeIFO27jWPh5YcjO+7OIiFaPkZrrhmL7RJkVfC3Z7NyrWvrxha95 clLtkvTrUFZS4RMIocQXxEAB5QXAYZ+sdHwNrmG+VipOygmn7HegoaZ2alec/1Ft1Zx+NuNSkx3 SK/TEEAxbu2XTQDoUxze7GgZXuAppUt8PddNazm6TLVIVfOw4K8xJi+sORQBL4ypC0InhBuIvJO WWMlousEkI8nmhYeBsTz6zs5Pt6wRkavAcmQahukbuszAjvyXOMyLlQsoRrMW9ib2n0Q0qLCwFw Pnpha/KwL1tElAPssAQ== X-Proofpoint-ORIG-GUID: POc5p69v3KWK1nuyq4YGZn2ST-ELoph9 X-Proofpoint-GUID: POc5p69v3KWK1nuyq4YGZn2ST-ELoph9 X-Authority-Analysis: v=2.4 cv=cKjQdFeN c=1 sm=1 tr=0 ts=6a019c34 cx=c_pps a=1Os3MKEOqt8YzSjcPV0cFA==:117 a=FpWmc02/iXfjRdCD7H54yg==:17 a=IkcTkHD0fZMA:10 a=NGcC8JguVDcA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=eoimf2acIAo5FJnRuUoq:22 a=EUspDBNiAAAA:8 a=NhS5FUBgDc7y_bOL5IQA:9 a=QEXdDO2ut3YA:10 a=hhpmQAJR8DioWGSBphRh:22 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.51,FMLib:17.12.100.49 definitions=2026-05-11_02,2026-05-08_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 adultscore=0 priorityscore=1501 bulkscore=0 impostorscore=0 clxscore=1015 spamscore=0 phishscore=0 malwarescore=0 lowpriorityscore=0 suspectscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2604200000 definitions=main-2605110100 On 5/9/26 1:31 AM, Thinh Nguyen wrote: > On Fri, May 08, 2026, Konrad Dybcio wrote: >> On 5/8/26 12:46 AM, Thinh Nguyen wrote: >>> On Thu, May 07, 2026, Jack Pham wrote: >>>> On Thu, May 07, 2026 at 12:34:50PM +0200, Konrad Dybcio wrote: >>>>> On 5/7/26 1:40 AM, Thinh Nguyen wrote: >>>>>> On Tue, May 05, 2026, Konrad Dybcio wrote: >>>>>>> From: Konrad Dybcio >>>>>>> >>>>>>> The Thunderbolt framework relies on the USB core to create device links >>>>>>> for tunneled ports, so that the USB3 controller is only kept >>>>>>> runtime-resumed for the duration of the tunneling. This depends on >>>>>>> first knowing whether a connection is tunneled or native. >>>>>>> >>>>>>> Add the logic to handle that for DWC3 controllers. >>>>>>> >>>>>>> Signed-off-by: Konrad Dybcio >>>>>>> --- >>>>>>> drivers/usb/dwc3/core.c | 12 ++++++++++++ >>>>>>> drivers/usb/dwc3/core.h | 18 ++++++++++++++++++ >>>>>>> drivers/usb/dwc3/host.c | 12 ++++++++++++ >>>>>>> 3 files changed, 42 insertions(+) >>>>>>> >>>>>>> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c >>>>>>> index 65213896de99..7cec4911e278 100644 >>>>>>> --- a/drivers/usb/dwc3/core.c >>>>>>> +++ b/drivers/usb/dwc3/core.c >>>>>>> @@ -162,6 +162,18 @@ void dwc3_set_prtcap(struct dwc3 *dwc, u32 mode, bool ignore_susphy) >>>>>>> } >>>>>>> EXPORT_SYMBOL_GPL(dwc3_set_prtcap); >>>>>>> >>>>>>> +enum usb_link_tunnel_mode dwc3_link_tunnel_mode(struct dwc3 *dwc, u8 port) >>>>>>> +{ >>>>>>> + /* Prior versions had no CIO support */ >>>>>>> + if (!DWC3_VER_IS_WITHIN(DWC31, 191A, ANY)) >>>>>>> + return USB_LINK_NATIVE; >>>>>>> + >>>>>>> + if (dwc3_readl(dwc, DWC3_CIOCTRL(port)) & DWC3_CIOCTRL_CIO_EN) >>>>>> >>>>>> The CIO register block only exists if DWC1_USB31_EN_CIO is set (and >>>>>> DWC_USB31_EN_USB2_ONLY is not set). In most cases, this register block >>>>>> will be reserved, register read of reserved block should be 0. But we >>>>>> can't guarantee that it will always be the case. >>>>> >>>>> That's inconvenient because.. >>>>> >>>>> [...] >>>>> >>>>>> We shouldn't need to be doing this. This should be checked from the >>>>>> xHCI driver. Check xHCI spec for PORTSC.TM and USB3 tunneling support >>>>>> capability (section 7.11). >>>>> >>>>> ..I'm seeing only caps 0/1/2 (and 10 on some but not all) advertised >>>>> (I ran a for-loop checking offsets 0..=255) >>>> >>>> Right. That section in xHCI spec was only added in the 1.2b revision. >>>> However the DWC31 IP versions that current Qualcomm USB4-capable SoCs >>>> are using are 2.00a (and a customized version of 1.91a) which are only >>>> compliant to xHCI 1.1 so this capability is not there, even though the >>>> CIO register block exists. So short of having the proper XHCI bit, this >>>> is the next best, non-SoC specific alternative we've found that can >>>> allow XHCI driver to identify when it is operating in tunnel mode. >>>> >>> >>> I see. If you're using 2.00a, then we can't use the xHCI's capability >>> register and PORTSC.TM. >>> >>> Can we match the compatible string to check for CIO capability and have >>> this passed from your glue driver before accessing the CIO registers? >> >> Hm, we currently use a shared compatible string for the USB3+4 (1.91a-xxx) >> and USB2 (3.30a) hosts on the USB4-capable platforms.. > > Ok. > >> >> Another idea would be to bail out if >> >> !device_property_present(dev, "usb4-host-interface") >> >> which would place the burden of making sure the DT makes sense on the >> programmer (which is OK in my view) >> > > For the DWC3_CIOCTRL_CIO_EN to be set, it needs to be done by the type-c > driver after detecting alternate mode right? How is it being done now? > Can the udev->tunnel_mode be updated directly by your type-c driver > when it sets DWC3_CIOCTRL_CIO_EN? For us, it seems to be hardwired (not sure if actually, but definitely effectively) to a separate register which is used to select the right clock mux for the USB3 protocol adapter to work (which is to be set if USB3 tunneling is going to be used) Moreover, the register definition for our SoCs calls all fields of CIOCTRL read-only, whereas the DWC programming guide says they're R/W - possibly supporting my theory above FWIW, our Type-C infra is as such: 1. thick firmware layer running on a MCU that performs mode&PD handshakes 2. drivers/soc/qcom/pmic_glink_altmode.c receives notifications of what the FW had negotiated with regards to mode 3. a relatively small subset of UCSI provides PD data (and some altmode data) 4. drivers/phy/qualcomm/phy-qcom-qmp-combo.c reprograms the PHY based on typec_mux events in native cases, or to USB4/TBT mode if the router driver requests it [that last part is not yet upstream] 5. [optionally] retimer drivers in between (most often Parade PS883x series via drivers/usb/typec/mux/ps883x.c), which act as an additional typec_mux/switch in the chain 6. [not upstream yet] USB4 router driver consumes some typec_mux parameters (orientation, cable and partner capabilities) and sends a command to another MCU to high-speed link establishment. It also sets the aforementioned magic register. At a glance, 2. seems like a reasonably fitting place to set it, however: * it does not have any sort of a handle to the typec_connector (it only acts like a mux that sets another mux), and * it may be going away in the future so I'd much prefer to keep this logic somewhere near where this iteration of the patch does - I think it'll be useful for more implementations, as I'd imagine it'd be fairly commonplace to hardwire CIOCTRL_CIO_EN and another part of the pipeline that must logically be online for USB4 to be useful +Sven, on ASi, is CIOCTRL_CIO_EN (dwc3base + (0xcd20 + ((port) * 0x30)) written to manually? Konrad