From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 0A0ADC43458 for ; Tue, 14 Jul 2026 20:11:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:MIME-Version:Reply-To:List-Subscribe: List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id:Message-Id:Date: References:In-Reply-To:Cc:To:Subject:From:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=K3wWv2aqZbxKS3l1p3TaNNi8NuNoOSq/aI8QIru2M44=; b=lB1Ug6fqM1UAiD t7svH+FgwxZ0K/EumkDgwkQdmyaRJ2bpQB4LvMHchtWmbFImSmAl0fvSlAZd49QCqAb5WWwhOH0UX H9Re38gUPq3V2JG4rHz5+Q6oOAiGXY0ukCKXYjfuUCMJSgZNcTXf/+5hk4Vu3MAhKS8zYnw/V4Mxe iqoAcjM+b0yIxdGcPZJe4kZWzdz+Wok3T7vpUAciQVyPRBQuQwiN/Wb+RoOpVKOqsyDjISEWaDWFU fCka03T0BZbmt2GQBiLgM6CrkT/VHWa0TaGYhm2HL2DXjMzkrubT6iijQMOdbNFQm4bwfX10JdvPF nrLekyb9AzjZRIObDNtg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wjjTr-0000000DCIC-2uxT; Tue, 14 Jul 2026 20:11:51 +0000 Received: from tor.source.kernel.org ([172.105.4.254]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wjjTq-0000000DCHu-0Kbk for linux-phy@lists.infradead.org; Tue, 14 Jul 2026 20:11:50 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id DE3CE601D9; Tue, 14 Jul 2026 20:11:47 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2CD381F00A3A; Tue, 14 Jul 2026 20:11:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1784059907; bh=k4QuKYpFrJbVJcIkqvZ2djSo0vSIsEarwQFfJgQe0qc=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=oOFSINDLSHliZdDcQ7Jp2iUk0rfaRfVhY4y8PKd3nF99WMtgRXPPmCiMhsE0ZmYfg jsJjzwjI+eGGlbSk/UGdRmXLHsloNMVW4mxBkaSKiCs7RoTZgnM2T2U9ErFr0XCB6p 7hUym5cRSHucNDz9vzviolsJqbTf50/7tKMO0GCvkpOtCsaXfiBNktrMYR7ERNS8Rv OETzXxOiowkp27XR5x60Z3+7WfF8eKKX6KnER7Huu91dWIhG0OQUvDTif9N1A73XRV FZ/UBcuMtZzBZidwJ7c/LbGyk5WSgVRMSUWPb+qCOP3l08wBB9GudILasEebvfryJz hi66fT0EJt1HQ== From: sashiko-bot@kernel.org Subject: Re: [PATCH v13 25/35] phy: rockchip: usbdp: Avoid xHCI SErrors To: "Sebastian Reichel" Cc: robh@kernel.org, vkoul@kernel.org, neil.armstrong@linaro.org, conor+dt@kernel.org, olteanv@gmail.com, linux-phy@lists.infradead.org, devicetree@vger.kernel.org In-Reply-To: <20260714-rockchip-usbdp-cleanup-v13-25-6cb3e769d4c5@collabora.com> References: <20260714-rockchip-usbdp-cleanup-v13-0-6cb3e769d4c5@collabora.com> <20260714-rockchip-usbdp-cleanup-v13-25-6cb3e769d4c5@collabora.com> Date: Tue, 14 Jul 2026 20:11:46 +0000 Message-Id: <20260714201147.2CD381F00A3A@smtp.kernel.org> X-BeenThere: linux-phy@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux Phy Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: sashiko-reviews@lists.linux.dev MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-phy" Errors-To: linux-phy-bounces+linux-phy=archiver.kernel.org@lists.infradead.org VGhhbmsgeW91IGZvciB5b3VyIGNvbnRyaWJ1dGlvbiEgU2FzaGlrbyBBSSByZXZpZXcgZm91bmQg MiBwb3RlbnRpYWwgaXNzdWUocykgdG8gY29uc2lkZXI6CgpQcmUtZXhpc3RpbmcgaXNzdWVzOgot IFtIaWdoXSBUaGUgaW5pdGlhbCBzZXR1cCBwYXRoIGZvciBgVURQSFlfTU9ERV9OT05FYCBpbmNv cnJlY3RseSByZS1lbmFibGVzIHRoZSBVU0IzIHBvcnQgd2hlbiB0aGUgZGV2aWNlIG9ubHkgc3Vw cG9ydHMgaGlnaC1zcGVlZCAoYHVkcGh5LT5ocyA9PSB0cnVlYCksIG92ZXJyaWRpbmcgaW50ZW50 aW9uYWwgY29uZmlndXJhdGlvbi4KLSBbSGlnaF0gVGhlIGRyaXZlciByZWxpZXMgb24gdGhlIGR5 bmFtaWNhbGx5IG11dGF0aW5nIGB1ZHBoeS0+bW9kZWAgdG8gZmlsdGVyIFBIWSBwb3dlci1vZmYg cmVxdWVzdHMsIHdoaWNoIGNhbiBwZXJtYW5lbnRseSBsZWFrIGVuYWJsZWQgY2xvY2tzIGlmIHRo ZSBUeXBlLUMgbW9kZSBjaGFuZ2VzIGJldHdlZW4gcG93ZXItb24gYW5kIHBvd2VyLW9mZi4KLS0K Ci0tLSBQYXRjaCBbMjVdOiBbUEFUQ0ggdjEzIDI1LzM1XSBwaHk6IHJvY2tjaGlwOiB1c2JkcDog QXZvaWQgeEhDSSBTRXJyb3JzIC0tLQpjb21taXQgYzk0ZmJhZjJhMjQ1ZTgxZDk0OWQwZGE5MDdh MmFjYjc5OWNlMTg0NgpBdXRob3I6IFNlYmFzdGlhbiBSZWljaGVsIDxzZWJhc3RpYW4ucmVpY2hl bEBjb2xsYWJvcmEuY29tPgoKICAgIHBoeTogcm9ja2NoaXA6IHVzYmRwOiBBdm9pZCB4SENJIFNF cnJvcnMKICAgIAogICAgVGhlIFVTQkRQIFBIWSBwcm92aWRlcyB0aGUgUElQRSBjbG9jayB0byB0 aGUgVVNCMyBjb250cm9sbGVyLCB3aGljaAogICAgbWVhbnMgdGhlIFBIWSBtdXN0IGJlIGZ1bGx5 IHJ1bm5pbmcgd2hlbiBhbnl0aGluZyB0cmllcyB0byBhY2Nlc3MKICAgIHRoZSB4SENJIHJlZ2lz dGVycy4KCj4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvcGh5L3JvY2tjaGlwL3BoeS1yb2NrY2hpcC11 c2JkcC5jIGIvZHJpdmVycy9waHkvcm9ja2NoaXAvcGh5LXJvY2tjaGlwLXVzYmRwLmMKPiBpbmRl eCBmYmEzNTUxMGQ4OGNlLi5jN2YwOTA0MDE4NWI2IDEwMDY0NAo+IC0tLSBhL2RyaXZlcnMvcGh5 L3JvY2tjaGlwL3BoeS1yb2NrY2hpcC11c2JkcC5jCj4gKysrIGIvZHJpdmVycy9waHkvcm9ja2No aXAvcGh5LXJvY2tjaGlwLXVzYmRwLmMKPiBAQCAtMTAwMCwyMyArOTkyLDI0IEBAIHN0YXRpYyBp bnQgcmtfdWRwaHlfcG93ZXJfb24oc3RydWN0IHJrX3VkcGh5ICp1ZHBoeSwgdTggbW9kZSkKPiAg CX0KPiAgCj4gIAlpZiAodWRwaHktPnN0YXR1cyA9PSBVRFBIWV9NT0RFX05PTkUpIHsKPiAtCQl1 ZHBoeS0+bW9kZV9jaGFuZ2UgPSBmYWxzZTsKPiAgCQlyZXQgPSBya191ZHBoeV9zZXR1cCh1ZHBo eSk7Cj4gIAkJaWYgKHJldCkKPiAgCQkJcmV0dXJuIHJldDsKPiAgCj4gIAkJaWYgKHVkcGh5LT5t b2RlICYgVURQSFlfTU9ERV9VU0IpCj4gIAkJCXJrX3VkcGh5X3UzX3BvcnRfZGlzYWJsZSh1ZHBo eSwgZmFsc2UpOwoKW1NldmVyaXR5OiBIaWdoXQpUaGlzIGlzbid0IGEgYnVnIGludHJvZHVjZWQg YnkgdGhpcyBwYXRjaCwgYnV0IHNob3VsZCB0aGUgY2hlY2sgYWJvdmUgYWxzbyAKdmVyaWZ5ICF1 ZHBoeS0+aHM/IAoKV2hlbiB0aGUgUEhZIGlzIGNvbmZpZ3VyZWQgZm9yIGhpZ2gtc3BlZWQgb25s eSwgcmtfdWRwaHlfdXNiM19waHlfaW5pdCgpIAppbnRlbnRpb25hbGx5IGRpc2FibGVzIHRoZSBV U0IzIHBvcnQuIElmIERQIGlzIGxhdGVyIGluaXRpYWxpemVkIGFuZCBlbnRlcnMgCnRoaXMgdWRw aHktPnN0YXR1cyA9PSBVRFBIWV9NT0RFX05PTkUgYnJhbmNoLCBpdCBhcHBlYXJzIHRoZSBVU0Iz IHBvcnQgd2lsbCBiZQp1bmNvbmRpdGlvbmFsbHkgcmUtZW5hYmxlZCwgb3ZlcnJpZGluZyB0aGUg ZXhwbGljaXQgaGlnaC1zcGVlZCBjb25maWd1cmF0aW9uLgoKWW91IGFkZGVkIHRoZSAhdWRwaHkt PmhzIGNoZWNrIHRvIHRoZSByZS1pbml0IGJyYW5jaCBiZWxvdywgd2hpY2ggcHJldmVudHMgCnRo aXMgaXNzdWUgdGhlcmUuIERvZXMgdGhlIGluaXRpYWwgc2V0dXAgYnJhbmNoIG5lZWQgdGhlIHNh bWUgY2hlY2s/Cgo+IC0JfSBlbHNlIGlmICh1ZHBoeS0+bW9kZV9jaGFuZ2UpIHsKPiAtCQl1ZHBo eS0+bW9kZV9jaGFuZ2UgPSBmYWxzZTsKPiAtCQl1ZHBoeS0+c3RhdHVzID0gVURQSFlfTU9ERV9O T05FOwo+IC0JCWlmICh1ZHBoeS0+bW9kZSA9PSBVRFBIWV9NT0RFX0RQKQo+IC0JCQlya191ZHBo eV91M19wb3J0X2Rpc2FibGUodWRwaHksIHRydWUpOwo+ICsJCXVkcGh5LT5waHlfbmVlZHNfcmVp bml0ID0gZmFsc2U7Cj4gKwl9IGVsc2UgaWYgKHVkcGh5LT5waHlfbmVlZHNfcmVpbml0KSB7Cj4g KwkJcmtfdWRwaHlfdTNfcG9ydF9kaXNhYmxlKHVkcGh5LCB0cnVlKTsKPiArCQl1ZGVsYXkoMTAp Owo+ICAKPiAtCQlya191ZHBoeV9kaXNhYmxlKHVkcGh5KTsKPiAtCQlyZXQgPSBya191ZHBoeV9z ZXR1cCh1ZHBoeSk7Cj4gKwkJcmV0ID0gcmtfdWRwaHlfaW5pdCh1ZHBoeSk7Cj4gIAkJaWYgKHJl dCkKPiAgCQkJcmV0dXJuIHJldDsKPiArCj4gKwkJaWYgKCF1ZHBoeS0+aHMgJiYgdWRwaHktPm1v ZGUgJiBVRFBIWV9NT0RFX1VTQikKPiArCQkJcmtfdWRwaHlfdTNfcG9ydF9kaXNhYmxlKHVkcGh5 LCBmYWxzZSk7Cj4gKwkJdWRwaHktPnBoeV9uZWVkc19yZWluaXQgPSBmYWxzZTsKPiAgCX0KPiAg Cj4gIAl1ZHBoeS0+c3RhdHVzIHw9IG1vZGU7CgpbIC4uLiBdCgo+IEBAIC0xMzAzLDM1ICsxMjc0 LDMwIEBAIHN0YXRpYyBjb25zdCBzdHJ1Y3QgcGh5X29wcyBya191ZHBoeV9kcF9waHlfb3BzID0g ewo+ICBzdGF0aWMgaW50IHJrX3VkcGh5X3VzYjNfcGh5X2luaXQoc3RydWN0IHBoeSAqcGh5KQo+ ICB7Cj4gIAlzdHJ1Y3QgcmtfdWRwaHkgKnVkcGh5ID0gcGh5X2dldF9kcnZkYXRhKHBoeSk7Cj4g LQlpbnQgcmV0ID0gMDsKPiAgCj4gLQltdXRleF9sb2NrKCZ1ZHBoeS0+bXV0ZXgpOwo+ICsJZ3Vh cmQobXV0ZXgpKCZ1ZHBoeS0+bXV0ZXgpOwo+ICsKPiAgCS8qIERQIG9ubHkgb3IgaGlnaC1zcGVl ZCwgZGlzYWJsZSBVMyBwb3J0ICovCj4gIAlpZiAoISh1ZHBoeS0+bW9kZSAmIFVEUEhZX01PREVf VVNCKSB8fCB1ZHBoeS0+aHMpIHsKPiAgCQlya191ZHBoeV91M19wb3J0X2Rpc2FibGUodWRwaHks IHRydWUpOwo+IC0JCWdvdG8gdW5sb2NrOwo+ICsJCXJldHVybiAwOwo+ICAJfQo+ICAKPiAtCXJl dCA9IHJrX3VkcGh5X3Bvd2VyX29uKHVkcGh5LCBVRFBIWV9NT0RFX1VTQik7Cj4gLQo+IC11bmxv Y2s6Cj4gLQltdXRleF91bmxvY2soJnVkcGh5LT5tdXRleCk7Cj4gLQlyZXR1cm4gcmV0Owo+ICsJ cmV0dXJuIHJrX3VkcGh5X3Bvd2VyX29uKHVkcGh5LCBVRFBIWV9NT0RFX1VTQik7Cj4gIH0KPiAg Cj4gIHN0YXRpYyBpbnQgcmtfdWRwaHlfdXNiM19waHlfZXhpdChzdHJ1Y3QgcGh5ICpwaHkpCj4g IHsKPiAgCXN0cnVjdCBya191ZHBoeSAqdWRwaHkgPSBwaHlfZ2V0X2RydmRhdGEocGh5KTsKPiAg Cj4gLQltdXRleF9sb2NrKCZ1ZHBoeS0+bXV0ZXgpOwo+ICsJZ3VhcmQobXV0ZXgpKCZ1ZHBoeS0+ bXV0ZXgpOwo+ICsKPiAgCS8qIERQIG9ubHkgb3IgaGlnaC1zcGVlZCAqLwo+ICAJaWYgKCEodWRw aHktPm1vZGUgJiBVRFBIWV9NT0RFX1VTQikgfHwgdWRwaHktPmhzKQo+IC0JCWdvdG8gdW5sb2Nr Owo+ICsJCXJldHVybiAwOwoKW1NldmVyaXR5OiBIaWdoXQpUaGlzIGlzIGEgcHJlLWV4aXN0aW5n IGlzc3VlLCBidXQgZG9lcyBldmFsdWF0aW5nIHRoZSBkeW5hbWljYWxseSBtdXRhYmxlCnVkcGh5 LT5tb2RlIGhlcmUgcmlzayBsZWFraW5nIHJlc291cmNlcz8KCklmIGEgVHlwZS1DIG11eCBldmVu dCBjaGFuZ2VzIHVkcGh5LT5tb2RlIChlLmcuLCBzd2l0Y2hpbmcgZnJvbSBVU0IrRFAgdG8gCkRQ LW9ubHkpIHdoaWxlIHRoZSBQSFkgaXMgYWN0aXZlLCB1ZHBoeS0+bW9kZSAmIFVEUEhZX01PREVf VVNCIHdpbGwgYmVjb21lCmZhbHNlLgoKV2hlbiB0aGUgVVNCIGZyYW1ld29yayBsYXRlciBwb3dl cnMgb2ZmIHRoZSBQSFksIHRoaXMgY2hlY2sgd2lsbCBhYm9ydCB0aGUKZXhpdCBlYXJseS4gVGhl IFVTQiBiaXQgaW4gdWRwaHktPnN0YXR1cyB3aWxsIHJlbWFpbiBzZXQgcGVybWFuZW50bHksIGFu ZCAKcmtfdWRwaHlfcG93ZXJfb2ZmKCkgd2lsbCBuZXZlciBmdWxseSBkaXNhYmxlIHRoZSBQSFkg YW5kIGl0cyBjbG9ja3MuCgpTaG91bGQgdGhpcyBpbnN0ZWFkIGNoZWNrIHRoZSBzb2Z0d2FyZSBw b3dlciBzdGF0ZSAodWRwaHktPnN0YXR1cykgcmF0aGVyCnRoYW4gdGhlIHJlcXVlc3RlZCBoYXJk d2FyZSBtb2RlPwoKPiAgCj4gIAlya191ZHBoeV9wb3dlcl9vZmYodWRwaHksIFVEUEhZX01PREVf VVNCKTsKPiAgCj4gLXVubG9jazoKPiAtCW11dGV4X3VubG9jaygmdWRwaHktPm11dGV4KTsKPiAg CXJldHVybiAwOwo+ICB9CgotLSAKU2FzaGlrbyBBSSByZXZpZXcgwrcgaHR0cHM6Ly9zYXNoaWtv LmRldi8jL3BhdGNoc2V0LzIwMjYwNzE0LXJvY2tjaGlwLXVzYmRwLWNsZWFudXAtdjEzLTAtNmNi M2U3NjlkNGM1QGNvbGxhYm9yYS5jb20/cGFydD0yNQoKLS0gCmxpbnV4LXBoeSBtYWlsaW5nIGxp c3QKbGludXgtcGh5QGxpc3RzLmluZnJhZGVhZC5vcmcKaHR0cHM6Ly9saXN0cy5pbmZyYWRlYWQu b3JnL21haWxtYW4vbGlzdGluZm8vbGludXgtcGh5Cg== From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 ADFAB423EAD for ; Tue, 14 Jul 2026 20:11:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784059908; cv=none; b=hW1OS4NL5cF9Fo/334km+VhxqnE5XqPeAnaliOjzmzC5aD5xam5yTu98Mh5ZoHj0s+rLG9rUjbcEwfHfWoDjFmB0FrSSTfE0a8XfwnbxtH0KYA51y1GqQ1YLWQXkw++TUv9yH3tNYhf80s7eZNEJg6ykI9ZImNdhcEb0XjyBuiQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784059908; c=relaxed/simple; bh=fMb796rr2K6ejaLVTgTn1duH2sA8bXgXtaY7GgtK064=; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date: Message-Id; b=SIniALIatvYUMEHlsUWB6pqno6yJcW552eLzPucuGO9vr4ARq5QtXAuafwh1FJluA0iKvsrJ8Tat+ErT5eX60h14UPrvtaFa3knuY6aXVCBQvr0UGYj6GovlY94FdUXeQ43lMncoF6yYZ0Cv56UHi5rWIdZYsHT4m2C1ZzhKOWg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=oOFSINDL; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="oOFSINDL" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2CD381F00A3A; Tue, 14 Jul 2026 20:11:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1784059907; bh=k4QuKYpFrJbVJcIkqvZ2djSo0vSIsEarwQFfJgQe0qc=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=oOFSINDLSHliZdDcQ7Jp2iUk0rfaRfVhY4y8PKd3nF99WMtgRXPPmCiMhsE0ZmYfg jsJjzwjI+eGGlbSk/UGdRmXLHsloNMVW4mxBkaSKiCs7RoTZgnM2T2U9ErFr0XCB6p 7hUym5cRSHucNDz9vzviolsJqbTf50/7tKMO0GCvkpOtCsaXfiBNktrMYR7ERNS8Rv OETzXxOiowkp27XR5x60Z3+7WfF8eKKX6KnER7Huu91dWIhG0OQUvDTif9N1A73XRV FZ/UBcuMtZzBZidwJ7c/LbGyk5WSgVRMSUWPb+qCOP3l08wBB9GudILasEebvfryJz hi66fT0EJt1HQ== From: sashiko-bot@kernel.org Subject: Re: [PATCH v13 25/35] phy: rockchip: usbdp: Avoid xHCI SErrors Reply-To: sashiko-reviews@lists.linux.dev To: "Sebastian Reichel" Cc: robh@kernel.org, vkoul@kernel.org, neil.armstrong@linaro.org, conor+dt@kernel.org, olteanv@gmail.com, linux-phy@lists.infradead.org, devicetree@vger.kernel.org In-Reply-To: <20260714-rockchip-usbdp-cleanup-v13-25-6cb3e769d4c5@collabora.com> References: <20260714-rockchip-usbdp-cleanup-v13-0-6cb3e769d4c5@collabora.com> <20260714-rockchip-usbdp-cleanup-v13-25-6cb3e769d4c5@collabora.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 14 Jul 2026 20:11:46 +0000 Message-Id: <20260714201147.2CD381F00A3A@smtp.kernel.org> Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Thank you for your contribution! Sashiko AI review found 2 potential issue(= s) to consider: Pre-existing issues: - [High] The initial setup path for `UDPHY_MODE_NONE` incorrectly re-enable= s the USB3 port when the device only supports high-speed (`udphy->hs =3D=3D= true`), overriding intentional configuration. - [High] The driver relies on the dynamically mutating `udphy->mode` to fil= ter PHY power-off requests, which can permanently leak enabled clocks if th= e Type-C mode changes between power-on and power-off. -- --- Patch [25]: [PATCH v13 25/35] phy: rockchip: usbdp: Avoid xHCI SErrors = --- commit c94fbaf2a245e81d949d0da907a2acb799ce1846 Author: Sebastian Reichel phy: rockchip: usbdp: Avoid xHCI SErrors =20 The USBDP PHY provides the PIPE clock to the USB3 controller, which means the PHY must be fully running when anything tries to access the xHCI registers. > diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rock= chip/phy-rockchip-usbdp.c > index fba35510d88ce..c7f09040185b6 100644 > --- a/drivers/phy/rockchip/phy-rockchip-usbdp.c > +++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c > @@ -1000,23 +992,24 @@ static int rk_udphy_power_on(struct rk_udphy *udph= y, u8 mode) > } > =20 > if (udphy->status =3D=3D UDPHY_MODE_NONE) { > - udphy->mode_change =3D false; > ret =3D rk_udphy_setup(udphy); > if (ret) > return ret; > =20 > if (udphy->mode & UDPHY_MODE_USB) > rk_udphy_u3_port_disable(udphy, false); [Severity: High] This isn't a bug introduced by this patch, but should the check above also= =20 verify !udphy->hs?=20 When the PHY is configured for high-speed only, rk_udphy_usb3_phy_init()=20 intentionally disables the USB3 port. If DP is later initialized and enters= =20 this udphy->status =3D=3D UDPHY_MODE_NONE branch, it appears the USB3 port = will be unconditionally re-enabled, overriding the explicit high-speed configuratio= n. You added the !udphy->hs check to the re-init branch below, which prevents= =20 this issue there. Does the initial setup branch need the same check? > - } else if (udphy->mode_change) { > - udphy->mode_change =3D false; > - udphy->status =3D UDPHY_MODE_NONE; > - if (udphy->mode =3D=3D UDPHY_MODE_DP) > - rk_udphy_u3_port_disable(udphy, true); > + udphy->phy_needs_reinit =3D false; > + } else if (udphy->phy_needs_reinit) { > + rk_udphy_u3_port_disable(udphy, true); > + udelay(10); > =20 > - rk_udphy_disable(udphy); > - ret =3D rk_udphy_setup(udphy); > + ret =3D rk_udphy_init(udphy); > if (ret) > return ret; > + > + if (!udphy->hs && udphy->mode & UDPHY_MODE_USB) > + rk_udphy_u3_port_disable(udphy, false); > + udphy->phy_needs_reinit =3D false; > } > =20 > udphy->status |=3D mode; [ ... ] > @@ -1303,35 +1274,30 @@ static const struct phy_ops rk_udphy_dp_phy_ops = =3D { > static int rk_udphy_usb3_phy_init(struct phy *phy) > { > struct rk_udphy *udphy =3D phy_get_drvdata(phy); > - int ret =3D 0; > =20 > - mutex_lock(&udphy->mutex); > + guard(mutex)(&udphy->mutex); > + > /* DP only or high-speed, disable U3 port */ > if (!(udphy->mode & UDPHY_MODE_USB) || udphy->hs) { > rk_udphy_u3_port_disable(udphy, true); > - goto unlock; > + return 0; > } > =20 > - ret =3D rk_udphy_power_on(udphy, UDPHY_MODE_USB); > - > -unlock: > - mutex_unlock(&udphy->mutex); > - return ret; > + return rk_udphy_power_on(udphy, UDPHY_MODE_USB); > } > =20 > static int rk_udphy_usb3_phy_exit(struct phy *phy) > { > struct rk_udphy *udphy =3D phy_get_drvdata(phy); > =20 > - mutex_lock(&udphy->mutex); > + guard(mutex)(&udphy->mutex); > + > /* DP only or high-speed */ > if (!(udphy->mode & UDPHY_MODE_USB) || udphy->hs) > - goto unlock; > + return 0; [Severity: High] This is a pre-existing issue, but does evaluating the dynamically mutable udphy->mode here risk leaking resources? If a Type-C mux event changes udphy->mode (e.g., switching from USB+DP to=20 DP-only) while the PHY is active, udphy->mode & UDPHY_MODE_USB will become false. When the USB framework later powers off the PHY, this check will abort the exit early. The USB bit in udphy->status will remain set permanently, and=20 rk_udphy_power_off() will never fully disable the PHY and its clocks. Should this instead check the software power state (udphy->status) rather than the requested hardware mode? > =20 > rk_udphy_power_off(udphy, UDPHY_MODE_USB); > =20 > -unlock: > - mutex_unlock(&udphy->mutex); > return 0; > } --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260714-rockchip-u= sbdp-cleanup-v13-0-6cb3e769d4c5@collabora.com?part=3D25