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 693763A16BA for ; Fri, 31 Jul 2026 07:33:16 +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=1785483197; cv=none; b=oNqLM+o4wRU17ZK2AsUZqBm0b0XTALabZSxUjK0VZr1ahuzpf/SCHidBou3bDg9Aa6dsRIEtb3QNCPSbhMbKkKJ82nrIMH6CeCJqgx2sJl9WxXxXEnYfWt+JijhYixlBSeKicqYWvAoEusLMhPAFl2F9lwrq3/paBm4memSDPjY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785483197; c=relaxed/simple; bh=YqmyT/qYu2cAbEn9E2TIrN4Qg2QW80P2POHFMYOKMz4=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version:Content-Type; b=TPH8i8zmtEnv3Dyak4xYfJEfA27F179ymdo+TnyZjMsqupla7HBdjjdYc1evbV1isi/x2jiRHWhemtTtYi76R/qVN6T0PY5LctVQZbuQJvpUPBsTB3TLoOzNBHJkx0noiiKzvpivgEwDRF7IzFlEVExoc3p5edc1hm8D7pKbg8c= 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=Imaswwqq; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=V2SkQtug; 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="Imaswwqq"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="V2SkQtug" Received: from pps.filterd (m0279863.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 66V7TUPc3532042 for ; Fri, 31 Jul 2026 07:33:15 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= vpdokqVBnZKXEDjkp04OU7LpdQXx434D5TMJ95t5YV8=; b=Imaswwqq8gmPTlZy t2dsZeH2OtJEn6rlV+uTaqGyuwvnpTkxgur6b/DFPs/2RHSXrnqVU+n4Lyv/XixS EgYbaahSV4R7XWLniAyXX8ywNS6JXNaJJoWPoQEkTH50xdIyAJBcCnIjnMB8MEJO LAL3MmQ6SRMG4QGZU0fjT+iOcMd3HH5dVx57aDEFNNDYwfhxCRdAwUWSY72rOyLK OaPAHzqLKf9VYwvLTRW4b38XHLcDkCU5aR6JmiZQX5TkTredskpOLRv8U/uY2pHo oyaU1+q1cPRuVmJFSBHelu0gQZyNf+6b+grUhPEQb1h7a3sXiBwGZOvln6fl1NEA uezBjg== Received: from mail-pl1-f199.google.com (mail-pl1-f199.google.com [209.85.214.199]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4frqc280cf-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Fri, 31 Jul 2026 07:33:15 +0000 (GMT) Received: by mail-pl1-f199.google.com with SMTP id d9443c01a7336-2cae7a8b9easo1003545ad.3 for ; Fri, 31 Jul 2026 00:33:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1785483195; x=1786087995; darn=vger.kernel.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to:content-type; bh=vpdokqVBnZKXEDjkp04OU7LpdQXx434D5TMJ95t5YV8=; b=V2SkQtugNtswbFHC4RjPP/Tm+fqBrS7X1jHvonr78I1GNRhA34X6dj0vxYieaEyvnQ ADWLmD+mEpWivv/kX54Xj1zj+tDsEurePeVgrkiZJ03PHiZfIs+sCEmzcOiblnlv4gXa YF8xibCjD/QFbUeun3bYOITmLcLTwoTKwqev1jmA6C1bw82jSWIz9ycsF/C1PgduQEKf Kf+M6p2ZK47Q4uaczuMZJEX3RIhwXXLy2ZkizPD+n/8ZKyuEH5s7CZhKd6VwBPQAx20i NObALY+aDSluWYtgbOLSuSHKlFKE7uWyLm1tlQjvMU4gv01WZcj88d37FJPloqzaj52r /fJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785483195; x=1786087995; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=vpdokqVBnZKXEDjkp04OU7LpdQXx434D5TMJ95t5YV8=; b=gmPvdEPTUKCg5lEqHA6vnwFKcTJNNwszDaf6fAC5lVv9qsulm9U17/RqrEi4dWf7Hy 1hBQi2okFouZcGXk5yMMqp+1EA9U1xqSvHyBGbEpWLc3N2rH5i8w7L/4IQfsj/GqkROl M9c1omuoizl0J+Oc+18ipqGGAgRenZVnNs3L6umIwDUdA/8dT+jXCbtDNO8HB69vQlMH qd3kP1ztRoOZa+sVaZhy1hcCu14FF6Kk9JdJ8P5s+nv5y6h8u+ui6fsNHPtT0YTYDAGf fCr1Ze5zyMwxqhM5OYZqXzs7s7mKba1b8LHu0f3jR2W2UpwkPuuDONjgpgahPSaGML8p DI6g== X-Forwarded-Encrypted: i=1; AHgh+RpWEOXfwBxwiom/uD/ACECltA4FAcq3BnhnRBrN27BkPDr6enpH+tkZvucVm6w9xAgL69zofER+1cOkFX4=@vger.kernel.org X-Gm-Message-State: AOJu0Yx9WwisDqXbZSERqAzp6YocM0O1+rCNhXFPhuXEjf9nG6H7xHup UKqVLcWXkRrVpxCM964+zkG6lEq008i2Vuz8RK/NfGD2Vj9pfqbHVaUKPDMh4JPvLK2q/BUeMQ4 NlxDWKs7PrdnMYkahgEQKrAzMzPb/jI3fAqrruWqoyu9X2w6ic7SVkFv7pbFKf5UZ3l4= X-Gm-Gg: AR+sD10P+VuexU0pWMdotfIgtr+dzbqnu85qFxOykDqqSjlCCUi7eTo7hngH4lo+AbM SmX3hbKfwNvLKjLLqS6TQ5ppmFzw9Ha7qX+o/jsIp6DbkTFmzaW6vqyuH4SU7ka7/GN58Xzd2qQ mAJZ4Jg/kUEfla8OenPaDkRAXBRXXa0Ux6yDWUIFUp2QpEMZXScAsBKxxcf91BfIgWVJPFCBfUe haNiPCNsVNd410vjOkO0RHx2bG1fxEEGJrpq8uNT4onvdAljFrrBs2f21b/QPXYEbuxg05kQWdX yU+qsyL5T+Z9xMkyiDxTshXoKtwywZKsoczMdCpjA+JXbbF12GMdIhhHQy7P6a5vnOicxlMhJYo 1vLh2NQ8iPoF24P0pp2M7cJHVsYT5Qs56kv/9YNagkCfMIcrNb7U= X-Received: by 2002:a17:902:ce06:b0:2cf:9e90:8be with SMTP id d9443c01a7336-2d046fa078amr17274585ad.4.1785483194666; Fri, 31 Jul 2026 00:33:14 -0700 (PDT) X-Received: by 2002:a17:902:ce06:b0:2cf:9e90:8be with SMTP id d9443c01a7336-2d046fa078amr17274125ad.4.1785483194200; Fri, 31 Jul 2026 00:33:14 -0700 (PDT) Received: from hu-weiden-sha.qualcomm.com (i-global052.qualcomm.com. [199.106.103.52]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-3153e18e70esm4933384eec.29.2026.07.31.00.33.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 31 Jul 2026 00:33:13 -0700 (PDT) From: Wei Deng To: Konrad Dybcio Cc: Bjorn Andersson , Rob Herring , Krzysztof Kozlowski , Conor Dooley , linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Manivannan Sadhasivam , Bartosz Golaszewski , Chen-Yu Tsai , quic_chezhou@quicinc.com, cheng.jiang@oss.qualcomm.com, shuai.zhang@oss.qualcomm.com, jinwang.li@oss.qualcomm.com, xiuzhuo.shang@oss.qualcomm.com, mengshi.wu@oss.qualcomm.com Subject: Re: [PATCH v3 1/3] arm64: dts: qcom: hamoa: Number usb_2 HS port and add M.2 endpoint stubs Date: Fri, 31 Jul 2026 13:03:06 +0530 Message-Id: <20260731073306.1895428-1-wei.deng@oss.qualcomm.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <8dd0680a-901a-465e-898d-88a17a9a71a4@kernel.org> References: <20260729-hamoa-m2-dts-v2-v3-0-4d7ef9274575@oss.qualcomm.com> <20260729-hamoa-m2-dts-v2-v3-1-4d7ef9274575@oss.qualcomm.com> <8dd0680a-901a-465e-898d-88a17a9a71a4@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwNzMxMDA1MiBTYWx0ZWRfX2U0tGeBx41SL ZMIrm1ZA92G/p13zs33N742+v4iAxUpn59aEnSjkPBun2ToHoiA1/mjLzhD2gUw5JPZSwJnCFYB RirebecFsFgKfAZqP6MhjhVcwCZcgKiMicCIgalZWUjZqOLxcGCIh6V3a2j5AM+klK3MYKal/Ss rS+bE3GZeoFZgqF9efQ0K1X9oKczDkAd2m4hzC+d0fbWry/Vnm3e1FLO4GHiVBbCCHrx2L2SUJc ZCHxgECNqJAHfJMq/BnLWOzx9RAO6OXGuRwiqwgNikKRSdY+n+q5oMS56TxMFGdi32eIGHMaq+9 QjmCTB4x2SOWhWbY8dI33oIiEzBHpAcVsg32BeK4FCjwR9/jStMibND99/9gNJWTA1yLhWOBhE5 ha3/cv3yiTrWzkAgLVKabxR8BwStJpztbn7JJpY0J2zmige+pPTGhuGnbXtfKjNodww3+butyGZ FEOE8XPnMksWFZXmizQ== X-Authority-Analysis: v=2.4 cv=dZSwG3Xe c=1 sm=1 tr=0 ts=6a6c4fbb cx=c_pps a=JL+w9abYAAE89/QcEU+0QA==:117 a=b9+bayejhc3NMeqCNyeLQQ==:17 a=IkcTkHD0fZMA:10 a=RAioF0-LDSMA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=yOCtJkima9RkubShWh1s:22 a=VwQbUJbxAAAA:8 a=cm27Pg_UAAAA:8 a=EUspDBNiAAAA:8 a=GMep2Sy8T26hx5v__mYA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=324X-CrmTo6CU4MGRt3R:22 X-Proofpoint-ORIG-GUID: 4YB0NWp-pvEchkPRponBOyEo-jalPlkm X-Proofpoint-GUID: 4YB0NWp-pvEchkPRponBOyEo-jalPlkm X-Proofpoint-Spam-Info: AW1haW4tMjYwNzMxMDA1MiBTYWx0ZWRfXwQChrHZLbwto bzzL06A6itlyGLAm+WVFIf1iNlPcjjWrGDYxlrAUuk24r/zRjT0QwFUkSfrcUNA37o9eAEwRFWZ 6csCewSkqK4rbkClkDSQk2LYw6tfen0= X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-07-31_02,2026-07-30_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 phishscore=0 lowpriorityscore=0 adultscore=0 spamscore=0 malwarescore=0 priorityscore=1501 clxscore=1015 bulkscore=0 suspectscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2607310052 Hi Konrad, On Wed, Jul 29, 2026 at 12:46:49PM +0200, Konrad Dybcio wrote: > On 7/29/26 12:27 PM, Wei Deng wrote: >> Number the existing High-Speed data bus port of the usb_2 DWC3 >> controller as port@0, consistent with the snps,dwc3 binding convention. >> >> Also add an empty port@1 endpoint stub (usb_2_m2_ep) for the USB 2.0 >> interface to M.2 peripherals, and an empty UART endpoint stub >> (uart14_ep) in the uart14 serial controller, so that board DTS files >> can reference these labels directly without re-entering the port >> hierarchy. >> >> Signed-off-by: Wei Deng >> --- > > [...] > >> - port { >> - usb_2_dwc3_hs: endpoint { >> + ports { >> + #address-cells = <1>; >> + #size-cells = <0>; >> + >> + port@0 { >> + reg = <0>; >> + >> + usb_2_dwc3_hs: endpoint { >> + }; >> + }; >> + >> + port@1 { >> + reg = <1>; >> + >> + usb_2_m2_ep: endpoint { >> + }; > > What? Why? > > 1. what's wrong with assigning the existing endpoint to the m2 graph? > 2. this breaks bindings - port@1 is supposed to represent the superspeed > connection > 3. why would we have two endpoints for the same physical HS connection? > > Konrad Thanks for the review. I tried (1) locally — repointing the existing usb_2_dwc3_hs endpoint at the M.2 graph and keeping the singular "port { endpoint { ... } }" structure — and hit a functional failure I'd like your and Chen-Yu's input on before v4. Test on Hamoa IoT EVK with the Chen-Yu Tsai V6 pwrseq series applied [1]: Option A (v3 as posted: ports { port@0 { usb_2_dwc3_hs }; port@1 { usb_2_m2_ep }; }): BT USB device enumerates; pwrseq_m2 refcount matches expectation. Option (1) (singular port { usb_2_dwc3_hs } with remote-endpoint pointing to M.2's port@2): BT USB does not enumerate; pwrseq_m2 refcount is 1 less than the Option A run. Root cause, following the V6 series: V6 patch 6 (usb: hub: Associate port@ fwnode with USB port device), for each USB roothub port, calls fwnode_graph_get_port_by_id(fwnode, port1, ...) where port1 is the USB port number (starts at 1). usb_2 is HS-only (maximum-speed = "high-speed", single usb2-phy), so this is called with port1 = 1 and looks up a DT node with reg = <1>. V6 patch 12 (pwrseq-pcie-m2: support matching on remote "port" node) uses of_graph_get_remote_port(endpoint) to match the USB port device's of_node against the M.2 endpoint's remote port. Under Option (1) the singular "port { }" has no reg, so port_by_id(1) returns NULL, port_dev->dev.of_node is left NULL, the pcie-m2 match falls through, pwrseq_get() is never called for the USB target, port->pwrseq stays NULL, and W_DISABLE2# is never deasserted from the USB path. That's the missing refcount and the failed enumeration. Under Option A, port@1's reg = <1> matches port1 = 1, graph walks all the way to the M.2 slot and pwrseq_get() succeeds. So on your (2) and (3): I don't disagree that "port@1 = SS" and "one endpoint per physical HS connection" are what the current snps,dwc3-common.yaml wants. The v3 shape is what works against the V6 fwnode lookup, not what I think is semantically clean. Choice seems to be between: (a) keep "port@1 = SS" — then USB port 1 on a HS-only DWC3 has nowhere to advertise its downstream connector node to the V6 lookup, and this M.2 wiring is not expressible; or (b) renumber snps,dwc3 ports to match USB port numbering (port@1 = HS if HS-only or SS if SS-capable, port@2 = HS if SS-capable), parallel to Chen-Yu's mediatek,mtk-xhci change in V6 patch 11 [2]. I want to avoid redefining the binding unilaterally, so two questions: Konrad: is there a DTS pattern I'm missing that would satisfy the current binding and still let fwnode_graph_get_port_by_id(fwnode, 1, ...) land on the M.2 connector for USB port 1? If not, would you be open to a snps,dwc3-common.yaml renumbering patch along the lines of Chen-Yu's mtk-xhci change? Chen-Yu: given the parallel with your patch 11, does snps,dwc3 need the same treatment on the QCom side, and would you rather see that patch go in ahead of your V6 or as a followup? The 3/3 sort-order comment will be fixed in v4 regardless. [1] https://lore.kernel.org/all/20260721065413.2306137-1-wenst@chromium.org/ [2] https://lore.kernel.org/all/20260721065413.2306137-12-wenst@chromium.org/ Thanks, -- Best Regards, Wei Deng