From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.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 1B7A936F434 for ; Thu, 26 Mar 2026 01:44:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.180.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774489481; cv=none; b=EL8gUFGReQQ7uecpDK/VsyJ/VddW5E1BhjHAsn8HcgUbC689yq09rApdFN7//fTkgV6xMw3iab7PalAdKf45XajMrkqkW/dp8rO/j0KXnKkZZcAazatmNaZoUCA+wEZk5nhtPEOXQdr0TRVevFHkDuev8g1g4Is9k7XX6CZqIcg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774489481; c=relaxed/simple; bh=l7f97CKt2YtMqwewMmAG7iRRlNaG2imV8RvlA0oPPB4=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=ppF+k/5tW080mjimD9bwk9Oe19+AEb9yzYEwXZ3hDw1Zc3rh5ZqFyIv00wI31j0Q2u8Jbhk3hHmxaA+k9MZt1CuBNG/hSqkLjlekbYi59ukTYa11AGPaIeZGceCyGJpPUjXB/fFT2VUTWeC18hAvAzDR3uufPLT1mSP+KBXKmkc= 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=SlstX98P; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=JKQCdlfL; arc=none smtp.client-ip=205.220.180.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="SlstX98P"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="JKQCdlfL" Received: from pps.filterd (m0279868.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 62PKkuju051542 for ; Thu, 26 Mar 2026 01:44:39 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= m6ez9EuGU+IEwV61QCocA0qqKSX45fjlTOqhijiaG7o=; b=SlstX98PkxclghRJ KvzNI9KeZdcrUZldgm7xtqeaqqlJd18rE1tVTE0HMpLWP9GZ5H06AxfNIH0AuJx6 Zv3V1aHGHspE4HSiCAzCOKsERYMlt+UKUL2g0YSOoKimBCLgxvnKVYWe5OzgILUG Qf9p6zZLRFwwPHGxHal8NaxIlylseRbdei8+fcnM2yT4dJMU5hz4NuZz4BN9+XAM YhqICRZn1HDZTo4pgV3UwE5G0Kw2TvAmbPw/1SjVXw0M5cWGYWXiDIDxSRL97olw A86I9LpLVF3NVYTgLy1AVLP2A6gJucQasO9qaWpBI1QGyf3gI8jsTCXYfOCTznPc KTykEA== Received: from mail-dy1-f198.google.com (mail-dy1-f198.google.com [74.125.82.198]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4d4q1t0qjy-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Thu, 26 Mar 2026 01:44:39 +0000 (GMT) Received: by mail-dy1-f198.google.com with SMTP id 5a478bee46e88-2c0d15416b3so1902362eec.1 for ; Wed, 25 Mar 2026 18:44:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1774489478; x=1775094278; 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=m6ez9EuGU+IEwV61QCocA0qqKSX45fjlTOqhijiaG7o=; b=JKQCdlfLtKnixx2JK/T3o57zl9QB8zjZr+Jac8fS2Khzfkduy5tvLhW/O9PU/DFDyK i11r86n2gkqZgkZiCQQ/tsUry5etgYlpL+8Wy68uxTJZs6BUh9/c2AGQ7qw48IRWaouG 1YsNCOeMQCaQe1o2xvGuptw0OzycIjBsnYRAEoZYImt3oL1diiR4L1eBInG0f+LOZCa7 zjGOvvRP/NM/VREoEbrkIHob7pjuua1XalZVuyXcmFQkWiqjOgxIMgOdal7nWNdc27Ao c0L6nltabvugGMaX6kstkfdmjaTCjCYFdqvzivCLlw3WnaR4yp1PhBT8+nUmuSGeWwGu keqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774489478; x=1775094278; 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=m6ez9EuGU+IEwV61QCocA0qqKSX45fjlTOqhijiaG7o=; b=sMadswgw0lCdTi8lAE/STEe5ukvcuMb3vWzxEc9tq5hnyNlr9yeNmVq2Qx87vw3I2t VNKTUBWs5R5/Tq4g2y1HFK5bvvT0205A0wDLEI0wnPIsJy7iO7oaywFWykrK/uwdzKxj xKAOlkwxYOXL6q7Q00Ou/y5SxQZHdXCVj9NU3lvw9DEuXFddeiE2ixkEU0AULAAxX+r4 JbE92rxK2QpdqkS1W+xc8hB5Z7tdCT2Q3RmXxdavHu0XjbDeClx0YkQC3Wk7XYLdUlFp ii/UxZOnTWnkF2PoTUNBVS6TiBHe9Ku70bXOQr2XOOldMrb7fyXFFLpAHZh78iwwc/gr K5WQ== X-Forwarded-Encrypted: i=1; AJvYcCXjuSLspeXY2VhW2gEbuzLHTnzkIBDoCqAaPi8lCLKI6M0b5ZvXJvuJKgrvTHvaGUwfdTT5TGEDu0zVNyg=@vger.kernel.org X-Gm-Message-State: AOJu0Yw0jy/pPzlL2nQwoiGvoTEh8Ot4Vot3ws+lBbX0rEP7D24Vj1dO KofY53xca2LbEA/5O0gChcJflCH+ZNf60XKfdmcbBQOK32yUF3++auh2UvOX3a+q0pSrxUaxhRE zzqcloOYriRAqxJVEaW3/7sbNIo3QPgfErgsuAD96ylVwaUuwajC9AsGKtVfn8FUWf0U= X-Gm-Gg: ATEYQzxA5BxnJW+hYCy4VheDcr2+Lf6yVq60ySHLpVgwgl+XjCl5fsJgGYilzLKLN1h QQCKydSb1B3cmiPEQFE1xWDzJy0qlsxwTAMBYsrFaUuOdK7mxq9UmWeGT2ch534J1Fd3V/0MJiM eSpnuX7qV2DRWdrQOa9qPrbLkWovrqL4Si9078k5VA8gD2I2NMNYsGEe8roUShPUG/4Z/YFbrpy FsMTo0OdZlnmpn3YAyjz2h9Sujm+lSPWi6S757OmHHUE1WqYgfAVAmq8+1RYJ/YDGst0hnEcUig E2amY4xR12xxNtz4kW+GqW0xJ16ZbGUHXpW5l66bGJnl3b1kOEdDoTSTovJRasdT8tWnzNANhnP A0QXXrCHDcVRsI6re82LfQglRe9yAQqBSXxDkeSFi6p7pJv9Fwh8= X-Received: by 2002:a05:7300:cd8a:b0:2c1:27c:75a0 with SMTP id 5a478bee46e88-2c15d340c05mr3216056eec.9.1774489477958; Wed, 25 Mar 2026 18:44:37 -0700 (PDT) X-Received: by 2002:a05:7300:cd8a:b0:2c1:27c:75a0 with SMTP id 5a478bee46e88-2c15d340c05mr3216033eec.9.1774489477341; Wed, 25 Mar 2026 18:44:37 -0700 (PDT) Received: from [192.168.1.132] ([70.95.199.79]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-2c16ec277edsm2104460eec.3.2026.03.25.18.44.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 25 Mar 2026 18:44:36 -0700 (PDT) Message-ID: <28c9c2b5-feeb-49ae-9d4c-51ac571ad8a1@oss.qualcomm.com> Date: Wed, 25 Mar 2026 18:44:35 -0700 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: =?UTF-8?Q?Re=3A_=5BPATCH_v2_0/1=5D_dt-bindings=3A_connector=3A_Add_?= =?UTF-8?Q?role=E2=80=91switch_provider_phandle?= To: Dmitry Baryshkov Cc: Rob Herring , Krzysztof Kozlowski , Conor Dooley , Heikki Krogerus , Bjorn Andersson , Konrad Dybcio , Wesley Cheng , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org References: <20260324172916.804229-1-elson.serrao@oss.qualcomm.com> Content-Language: en-US From: Elson Serrao In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Authority-Analysis: v=2.4 cv=e7cLiKp/ c=1 sm=1 tr=0 ts=69c48f87 cx=c_pps a=wEP8DlPgTf/vqF+yE6f9lg==:117 a=uHxescsG3rBdxcXwcPaeSg==:17 a=IkcTkHD0fZMA:10 a=Yq5XynenixoA:10 a=5KLPUuaC_9wA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=ZpdpYltYx_vBUK5n70dp:22 a=EUspDBNiAAAA:8 a=FUNPCKqUHVlFUV5SY1YA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=bBxd6f-gb0O0v-kibOvt:22 X-Proofpoint-GUID: VuptSOOAQWRtYdBLEf-ZLpJNBWQqS93l X-Proofpoint-ORIG-GUID: VuptSOOAQWRtYdBLEf-ZLpJNBWQqS93l X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMzI2MDAxMSBTYWx0ZWRfXyGvNwPqVvzN0 uirH56yD6Bv/Z2DX3B9sn7nXQqmSiQB+7hFPu8kC6U+fMM/G+zy8EjTj8e5wQnZBej2EBH6U7L4 69qMAuw58baMAqV/PN4iHM4pyFVttea5WvFYD4nnS2m+qw514zFjzfmSY0mLWnBibuRJKKMJPJD qhSa9/0nD/Qx6Inty0YFly+Wq+rQWLLMaoL8U2IJWx83JiJOvXjZ8pAuI4Kr+qGlnYtqbzx5VtZ epgPD/95iGxANFBUpilmtbY5W3Xf0jmLVSGkvXVwwtWR96+4Wlp3T5y6AvCWtbet+Skl0VRp/rs MUTmN8FjbY42VmgcJxV33aVdIMd8wNxy06mgQf0OHCP9wSaDts5K53Q7lO56ljWRQ4fnC1jWuwj NN7t51gIEp/GXHbM6ideJ8AoDwCGkO7RNXF+B2NNVecCb3ypyAtEVSmL4buu0DhI6kMTar+bbnC wNF2M9d+VrcuZxiPRmw== 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-03-26_01,2026-03-24_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 impostorscore=0 spamscore=0 bulkscore=0 phishscore=0 suspectscore=0 clxscore=1015 lowpriorityscore=0 malwarescore=0 adultscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2603050001 definitions=main-2603260011 On 3/24/2026 10:46 AM, Dmitry Baryshkov wrote: > Hello, > > On Tue, 24 Mar 2026 at 19:29, Elson Serrao > wrote: >> >> Hi all, >> >> This patch proposes a generic Devicetree mechanism for a USB connector to >> reference the USB role‑switch provider when there is an intermediate, >> block between the connector and the controller in the OF graph. > > Please, don't describe what the patch or the change does, see > Documentation/processes/submitting-patches.rst. > >> >> Problem >> ======= >> OF‑graph links are strictly point‑to‑point via remote-endpoint, so a >> consumer can only discover its immediate neighbor in the graph. When an >> intermediate node sits between the USB connector and the controller, the >> connector cannot identify the controller (the role‑switch provider) from >> the graph alone. > > DT is a hardware description. Here you are trying to describe the > software behaviour. Please don't mix those. > > [skipped diagrams] > >> >> From the OF‑graph structure alone, Conn‑0 cannot determine that >> USBCtrl‑0 (and not USBCtrl‑1) is the correct role‑switch provider. >> >> Proposal >> ======== >> Add an optional consumer→provider phandle on the connector: >> >> usb-role-switch = <&controller>; > > An alternative proposal: let EUD register as a role-switch and then > retranslate usb-role-switch events. This is how it is handled by the > Type-C-related objects (muxes and orientation switches). > Hi Dmitry, Thank you for the review and suggestions. To better understand the intended model: are you proposing that the EUD register a separate usb‑role‑switch instance per connector → controller relationship, or a single role‑switch instance representing the EUD as a whole? I understand the analogy with Type‑C muxes and orientation switches, which are typically modeled on a per‑connector basis. In contrast, the EUD hardware block spans multiple connectors and controllers and can carry traffic from multiple independent USB connections concurrently. For example: - Connector0 operating in host mode (connected to Controller0) - Connector1 operating in device mode (connected to Controller1) - Both active at the same time In such a scenario, a single role‑switch instance representing both connectors appears ambiguous, as different roles may be active simultaneously on different ports. Registering multiple role‑switch instances—one per connector/controller pair—would avoid that ambiguity. However, this would imply a single EUD device registering multiple role‑switch instances associated with the same firmware node. As the USB role‑switch framework currently assumes a 1:1 relationship between a firmware node and its role‑switch instance, this would likely require non‑trivial changes to USB role switch framework on how role‑switch instances are represented and managed. Thanks, Elson