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 9CBFD36C5B6 for ; Mon, 23 Feb 2026 19:10:46 +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=1771873848; cv=none; b=U59uLJDXyF7K4wXZwWVy4802bZPv+M2rhqrKFYPuUMfMmGfKu2Qxf0F+urgmZINz+l8cq5iI5LF3GGp/1/vTqixhcSgK88hrj/P5EPEUR5CahpC49DRPlxcpmEznRgRec/nrwrn8pgxR83V9AQGwDBhPwS4iVnrs/tcJkeSj3yc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771873848; c=relaxed/simple; bh=IrnseUpd8gT8z82b3zfzFcQlz0NAUvy0SeRFzBbHVc4=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version:Content-Type; b=ShBuS+cNHjhmv2qlJ7KQNTjWMso29RXqwfunn0F/foC5YHVlHdRT4BEHCl7N+0A/uQ+vuZojoMxrFkXLiXO6mkzZEX0EoB8jOajQDgQw94MY+00cD77DOx69tUyTI7tmofznX1xAySq6bdowYPe0jB4ZXtG0UJ5ZJr32ZEZjnAA= 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=DIRhN4j5; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=aGlD0LSn; 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="DIRhN4j5"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="aGlD0LSn" Received: from pps.filterd (m0279869.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 61NGRLUZ1640663 for ; Mon, 23 Feb 2026 19:10:45 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h= cc:content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to; s=qcppdkim1; bh=ZfAXXZfZFZznm6XeMrxkA0 kaozX7UR/VjB5pRxEAVnk=; b=DIRhN4j5b7ZY7iulJA4IshsbYO2ohQNvUR03Y3 vJcAJB13rKxwt+T2qphXgUtWYpzE47MOFh2RwHO+60Q4RSfxG459PscFGRMQZvD2 J1TK4pUyMvnNjPnyZTrhEq4iSpyt2HVW13Xods9hCCtC/RT+YoFE3/MdogOaJfRe ktf25MH02qVXvVIv60P5l2NgX/7RCygYTR5OwuN0PbM4S+esf5IEP1sg8hMraUnC 1Wc0uRCqI5NDGqW9LwUd1jkKN3wim3/Barv9kgAxH/u1zURDilqJBQojGWO3QxKi L4uONYVf9oohKVIj9gb/dSp9XWU8Sk/1Bwu+m1MmBTgcG0mg== Received: from mail-oa1-f71.google.com (mail-oa1-f71.google.com [209.85.160.71]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4cgte8rhgb-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Mon, 23 Feb 2026 19:10:45 +0000 (GMT) Received: by mail-oa1-f71.google.com with SMTP id 586e51a60fabf-40f05300c94so47668886fac.1 for ; Mon, 23 Feb 2026 11:10:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1771873845; x=1772478645; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=ZfAXXZfZFZznm6XeMrxkA0kaozX7UR/VjB5pRxEAVnk=; b=aGlD0LSnlSSdyJjymCc1svB3jf/3qtkZ5rzN0rp80sXawGQkETXVgvruQbamZH3JmC rd1XrhZBlYNvsxT+ploFD4lZwbUVv8RKLkfw2Zt9elhMMWlnUD8Q5Xdecn2smwuQmtrV fuTqbN3G1u3TmszLVBrQWYhloGn+zeRkWyAU1rqIpzu2Onfd2nYyJdIONj/3OVhm5Xx2 Hjkn+g31oQLfUQY35s/OBrM+nwpcy+dQedDfIiLxJzt2eQBW6qJAzUXbgp3WUTH5b4rM 2hCyHucdT1UuVMHdpl9SPUi6gptNKzVw5AZG4H+3eBDA0oxLPaoFKsvlv2ovqwoIpbPP MDvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771873845; x=1772478645; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ZfAXXZfZFZznm6XeMrxkA0kaozX7UR/VjB5pRxEAVnk=; b=uOOTg7BL7VqDhEJGvrSxXfqRb/SqyqqDw8NNL/3+eViEzpkw7TStfTi7EJ23rRO8O0 +29EsLHMbLQ8tN15z0YU9Kj7LBxeleeijRJusMwfiF5heTws0IyHcPlyUtksIe/pNoH3 tzz8mAWxg2jIpoK7Z1AK/qWZxXyXVEmo6a6m7ZwbD4g4OojF5PJBTUJBdYmAEOhFJ4Nv Rt+QqXdfwXmvEu5fYlTTyKsWHrpifwYy52QWZsouP/VeRGFai6H+Eo+4JAH/OTlDHfRg 8xX6sIU3E7QDTg71pFmeqUdHMj7gubuYIcgsM+Xgyv0Y+IIMMgCMdw+e3kky/aG7RKHn uAvw== X-Forwarded-Encrypted: i=1; AJvYcCU5YPR1E3+adoWBE7kwQt/EWa3coDOt1sSfTiwHVDvwkTn6cD+Qa3IE4C9uODe0x1ZuViQFElt2hXZAVSY=@vger.kernel.org X-Gm-Message-State: AOJu0YyJ9rIxzPehnr9ZaRa2uq7U8smQ2q2x20vymtP60f60jkWo32ql FGej6dWo8NfpUA/yxICVirJFQob8diGFMKCYXlXkbo9nLw5kxg2il1VSGSHGsnh1oKfbVczC8fl UtLzytfhEwVEstvn4sMwqk63Q93FtDgfyIo4unKQmXGdv5zDSfAK9y20BYEpFTP4xrg4= X-Gm-Gg: AZuq6aJQ1RWxB+NHPczUjNSaBZ3O71+/C4iNTRx4QVb9tslGkU8DbPUqdURKVZWNazP +nlzp7x8ZDGkPGin+KYb7T+9jXIJrH/DB+6eYcXegdg05SOWiqlmzUmLRsmKoe3It5L2iEaYW0l 0Z62l+jjooZKFZK4m1sQVOdtStQFsUPbEg5c1J15utDf/ex/jDJ894U6deNwkKKWHMSTtF0DzXr KcKLu6cc4QJ/91J4N1BLrMzyVE3lCCwm/vdFFFs8qiSDJdd3nI2HLgcnobwjGJsc9bRbdNiA55d hebAch6qAdb9fF/y570jmtxZj3yZQNToM6J4/WZZ/77Ul8Xkfy7Ifyp1cK4JR9WIUNQ/Vgms2FY O6/IjuMrY5RTQmUHLTd6wnkhw7atR2jNL2y8ZGZkqCGKWDJn+dX9yV2s/M8GWnA9xQJx/FWbLjq o= X-Received: by 2002:a05:6871:ea13:b0:3dd:6bdb:e741 with SMTP id 586e51a60fabf-4157b0ea2a6mr4963121fac.26.1771873844665; Mon, 23 Feb 2026 11:10:44 -0800 (PST) X-Received: by 2002:a05:6871:ea13:b0:3dd:6bdb:e741 with SMTP id 586e51a60fabf-4157b0ea2a6mr4963104fac.26.1771873844269; Mon, 23 Feb 2026 11:10:44 -0800 (PST) Received: from hu-eserrao-lv.qualcomm.com (Global_NAT1.qualcomm.com. [129.46.96.20]) by smtp.gmail.com with ESMTPSA id 586e51a60fabf-4157d2d77e3sm8580902fac.13.2026.02.23.11.10.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 23 Feb 2026 11:10:43 -0800 (PST) From: Elson Serrao To: Rob Herring , Krzysztof Kozlowski , Conor Dooley , Bjorn Andersson , Dmitry Baryshkov , Konrad Dybcio , Wesley Cheng Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [RFC PATCH 0/1] dt-bindings: connector: Add role‑switch provider phandle Date: Mon, 23 Feb 2026 11:10:41 -0800 Message-Id: <20260223191042.825136-1-elson.serrao@oss.qualcomm.com> X-Mailer: git-send-email 2.34.1 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-ORIG-GUID: ez-LskMZ6OESUmywKSO5paYejVyEfHl3 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMjIzMDE2NiBTYWx0ZWRfX7H5nE56y3dtd mvHznKSv3s8ys37cY9ptTDHREvLN81GY0FLKlDOjwjHu2hTMDVNoHFUojtFLZ7pxO19nRs0bohi 7PHzMsxyc+j50WHPl92vxe0qI9kOBhZ10WLyvh4DakMGJfps4DVn/kXKkFQBWs8V3eH73ZW8Mbe HUlT07mktHA2lchzxCMklkJeYmAh0v9JdGQJdq4/VtS0hkgI0KcFSOzYg6aYnFQk+lqvHS6Sh61 vhox7CBgOXFesGmE8fa0izyn0YdzytX1hz4vmm+ROP8k9sC9RUfjlBmF5FMgWUVnkWC7HjorIhg XS0nl4mi3u/dwwYDQKQr4ylaEcr7Bg7WJ/2krN07pqOIHOUlsxl0YzGijwyYLb6H79YkqeHEgxd W4rtELVAkSkENhIX+3SlQsSzyX+GjZLqg+ozJJziOUb0ncKFTDTBZR2mU1LHj4aGCXF7/8QTAAw idLVCXrLhk2K2y9g1Jg== X-Proofpoint-GUID: ez-LskMZ6OESUmywKSO5paYejVyEfHl3 X-Authority-Analysis: v=2.4 cv=WqQm8Nfv c=1 sm=1 tr=0 ts=699ca635 cx=c_pps a=CWtnpBpaoqyeOyNyJ5EW7Q==:117 a=ouPCqIW2jiPt+lZRy3xVPw==:17 a=IkcTkHD0fZMA:10 a=HzLeVaNsDn8A:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=_glEPmIy2e8OvE2BGh3C:22 a=VwQbUJbxAAAA:8 a=suRUVlQjLIQ7l_8mqXEA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=vh23qwtRXIYOdz9xvnmn:22 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1121,Hydra:6.1.51,FMLib:17.12.100.49 definitions=2026-02-23_04,2026-02-23_03,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 bulkscore=0 phishscore=0 suspectscore=0 adultscore=0 priorityscore=1501 spamscore=0 impostorscore=0 clxscore=1015 malwarescore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2602130000 definitions=main-2602230166 Hi all, This RFC 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. 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. Example (illustrative only) =========================== On some Qualcomm SoCs, an Embedded USB Debug (EUD) block sits electrically between USB‑C connectors and DWC3 controllers. EUD models HS wiring only . Below is a simplified diagram of the hardware paths: EUD Block +------------------------------+ | | [Conn-0]-->[USB2PHY-0]---->|-------- Path 0 --------------|-->[USBCtrl-0] | | [Conn-1]-->[USB2PHY-1]---->|-------- Path 1 --------------|-->[USBCtrl-1] | | | +------------------+ | | | EUD Debug Hub | | | +------------------+ | +------------------------------+ And the corresponding OF‑graph mapping # Node: EUD (intermediate; graph-only for HS) (extending [1] to dual port) EUD (eud@...) └── ports ├─ port@0 (reg = <0>) │ └─ endpoint ── remote-endpoint ──> USBCtrl-0 │ ├─ port@1 (reg = <1>) │ └─ endpoint ── remote-endpoint ──> Conn-0 │ ├─ port@2 (reg = <2>) │ └─ endpoint ── remote-endpoint ──> USBCtrl-1 │ └─ port@3 (reg = <3>) └─ endpoint ── remote-endpoint ──> Conn-1 # Node: Connector 0 Conn-0: usb-connector └── port └─ port@0: endpoint --> remote-endpoint --> EUD:port@1 # Node: USB Controller 0 USBCtrl-0: usb@... (e.g., DWC3-0) └── port └─ port@0: endpoint --> remote-endpoint --> EUD:port@0 # Node: Connector 1 Conn-1: usb-connector └── port └─ port@0: endpoint --> remote-endpoint --> EUD:port@3 # Node: USB Controller 1 USBCtrl-1: usb@... (e.g., DWC3) └── port └─ port@0: endpoint --> remote-endpoint --> EUD:port@2 >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>; The provider remains the controller node, which already declares the boolean 'usb-role-switch;' and registers the role‑switch device. Request ======= Please confirm whether adding an optional connector-side provider phandle is an acceptable general pattern for these topologies. If there is a more appropriate DT modeling approach for this scenario, I would appreciate your guidance. Thanks for your time and review. Best regards, Elson Serrao [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml?h=v6.19 Elson Serrao (1): dt-bindings: connector: Add role‑switch provider phandle .../devicetree/bindings/connector/usb-connector.yaml | 8 ++++++++ 1 file changed, 8 insertions(+) -- 2.34.1