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 18EE8C5CFCF for ; Fri, 14 Aug 2026 05:43: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=NlS7n0c1oU24RLrzuxmv9UhjeX2fQ5RyJ6m7yDp3kME=; b=ZzkNRNLwdwFu+k gN2pGB60uE1GmyDlXtzvDgNsW+vmMtzKIWqunQQgHmpZShJVequKoBRnLkfgXmhN5EghzFIvLr3nI ZBlGVPiQitNld2ea28p9MPCIhms8yfYKLGCmh0ZUygsb56eovXmxfMwabhCmITgJfPchLdzry26Uj rOCzaBHiPO0XutuKZYGAACj311buGZXvigG1Q1kpNPS5yPLhVVdsCBGCoA7GRIRFyXnm3IKM9motv tMZxnvbtNpFkb8xSaw27fbSOEuoE1hGm1qbrcxM4YXPEiiEeKcMxf4uDqKs/VBoMXKjruaEVGyw59 aBYjmDGZyrrIJyeMN5pg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wukhs-00000001zQO-2CPq; Fri, 14 Aug 2026 05:43:52 +0000 Received: from tor.source.kernel.org ([2600:3c04:e001:324:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wukhr-00000001zQ5-1T9T for linux-phy@lists.infradead.org; Fri, 14 Aug 2026 05:43:51 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 31B9B601E0; Fri, 14 Aug 2026 05:43:50 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6DFEC1F000E9; Fri, 14 Aug 2026 05:43:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786686229; bh=1g6A5FvJ5WXw8UL/HnxMF3zluG9HVvl6rg26A3xq++g=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=el2uGqgwpZZJ32YdnHGPEu1NLuJTK+aCP0XEESGldgvBJ6rcNRX0VF56g+sQKYury YtigZ6De6BpHqFU4ufkM4K7qD2pMBglVtyWKAhu+n4pcQ/DXtMIHBj8Ibbe+DV8Net iH6YZY8NBCeoxKsstK2pvGpdBXNPxoqrzdsxvzITbj6QGyLqfhEiDCZLEcyYSVcF34 66/H6Gpovqc4I9WqUa/bE7eJaTOAlGzIURGBE8RtZpBo+s/XCbI80/H6EnFpw5SPjn ZHnNVUTAp8mTdwP2//UDmKIUhmMGNHDL7d5C/FOwxbaHQ6Jpg+wRzyVquuT5Gyqi9M YXQTF3lfirtpQ== From: sashiko-bot@kernel.org Subject: Re: [PATCH v14 31/38] usb: dwc3: rockchip: support PHY reset notifications To: "Sebastian Reichel" Cc: robh@kernel.org, devicetree@vger.kernel.org, olteanv@gmail.com, vkoul@kernel.org, linux-phy@lists.infradead.org, neil.armstrong@linaro.org, conor+dt@kernel.org In-Reply-To: <20260813-rockchip-usbdp-cleanup-v14-31-b5ad9c68fa11@collabora.com> References: <20260813-rockchip-usbdp-cleanup-v14-0-b5ad9c68fa11@collabora.com> <20260813-rockchip-usbdp-cleanup-v14-31-b5ad9c68fa11@collabora.com> Date: Fri, 14 Aug 2026 05:43:48 +0000 Message-Id: <20260814054349.6DFEC1F000E9@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 MiBwb3RlbnRpYWwgaXNzdWUocykgdG8gY29uc2lkZXI6Ci0gW0hpZ2hdIFRoZSBQSFkgbm90aWZp Y2F0aW9uIGhhbmRsZXIgdW5jb25kaXRpb25hbGx5IGRyb3BzIGEgUE0gdXNhZ2UgcmVmZXJlbmNl IGlmIGBwbV9ydW50aW1lX2dldF9pZl9hY3RpdmUoKWAgcmV0dXJucyBgLUVJTlZBTGAsIGNhdXNp bmcgYSB1c2FnZSBjb3VudGVyIHVuZGVyZmxvdyBhbmQgcG90ZW50aWFsbHkgZHJvcHBpbmcgcmVm ZXJlbmNlcyBvd25lZCBieSBvdGhlciBwYXJ0cyBvZiB0aGUgZHJpdmVyLgotIFtIaWdoXSBUaGUg UEhZIG5vdGlmaWVyIHVucmVnaXN0cmF0aW9uIGlzIGRlZmVycmVkIHRvIHRoZSBkZXZyZXMgdGVh cmRvd24gcGhhc2UsIGNyZWF0aW5nIGEgcmFjZSBjb25kaXRpb24gd2hlcmUgYW4gYXN5bmNocm9u b3VzIFBIWSByZXNldCBldmVudCBhY2Nlc3NlcyB1bmNsb2NrZWQgYW5kIHJlc2V0IERXQzMgaGFy ZHdhcmUsIGNhdXNpbmcgYSBrZXJuZWwgcGFuaWMuCi0tCgotLS0gUGF0Y2ggWzMxXTogW1BBVENI IHYxNCAzMS8zOF0gdXNiOiBkd2MzOiByb2NrY2hpcDogc3VwcG9ydCBQSFkgcmVzZXQgbm90aWZp Y2F0aW9ucyAtLS0KY29tbWl0IGY0NThiNGMyMTM4OTlmNTBmMWQ0MGM1MmY3YzVhYWViMzhmZGI2 NzUKQXV0aG9yOiBTZWJhc3RpYW4gUmVpY2hlbCA8c2ViYXN0aWFuLnJlaWNoZWxAY29sbGFib3Jh LmNvbT4KCnVzYjogZHdjMzogcm9ja2NoaXA6IHN1cHBvcnQgUEhZIHJlc2V0IG5vdGlmaWNhdGlv bnMKCk9uIHJlY2VudCBSb2NrY2hpcCBwbGF0Zm9ybXMgKGF0IGxlYXN0IFJLMzU4OCAmIFJLMzU3 NiksIERXQzMgSVAgaXMgdXNlZAp3aXRoIGEgVVNCRFAgUEhZIHByb3ZpZGluZyBVU0IzIGFuZCBE UC4gVGhpcyBQSFkgbmVlZHMgdG8gYmUgcmVzZXQgd2hlbgp0aGUgbW9kZSBjaGFuZ2VzLCB3aGlj aCBtYXkgaGFwcGVuIHdoZW4gcGx1Z2dpbmcgaW4gZGlmZmVyZW50IFVTQi1DCmRldmljZXMuIFRo aXMgYWRkcyBoYW5kbGluZyBmb3IgdGhlIG5ldyBQSFkgZnJhbWV3b3JrIHJlc2V0IG5vdGlmaWNh dGlvbnMuCgo+IGRpZmYgLS1naXQgYS9kcml2ZXJzL3VzYi9kd2MzL2R3YzMtcm9ja2NoaXAuYyBi L2RyaXZlcnMvdXNiL2R3YzMvZHdjMy1yb2NrY2hpcC5jCj4gaW5kZXggMWRmMzM2MjViNjlmOC4u OWU5MWU1ZjdlNTNkNiAxMDA2NDQKPiAtLS0gYS9kcml2ZXJzL3VzYi9kd2MzL2R3YzMtcm9ja2No aXAuYwo+ICsrKyBiL2RyaXZlcnMvdXNiL2R3YzMvZHdjMy1yb2NrY2hpcC5jClsgLi4uIF0KPiAr c3RhdGljIGludCBkd2MzX3VzYjNfcGh5X25vdGlmeShzdHJ1Y3Qgbm90aWZpZXJfYmxvY2sgKm5i LAo+ICsJCQkJdW5zaWduZWQgbG9uZyBhY3Rpb24sIHZvaWQgKmRhdGEpCj4gK3sKWyAuLi4gXQo+ ICsJc3dpdGNoIChhY3Rpb24pIHsKPiArCWNhc2UgUEhZX05PVElGWV9QUkVfUkVTRVQ6Cj4gKwkJ LyoKPiArCQkgKiBJZiBhbHJlYWR5IHN1c3BlbmRlZCwgdGhlIHJlc3VtZSBwYXRoIHdpbGwgcmVp bml0IEdVU0IzUElQRUNUTAo+ICsJCSAqIHZpYSBkd2MzX2NvcmVfaW5pdCgpLiBBIGZvcmNlZCBy ZXN1bWUgaXMgbm90IHBvc3NpYmxlIGFzIHRoYXQKPiArCQkgKiB3b3VsZCBjYWxsIHBoeV9pbml0 KCkgcmVzdWx0aW5nIGluIGEgZGVhZGxvY2suIER1ZSB0byB0aGUKPiArCQkgKiBwaHlfaW5pdCgp IGluIHRoZSByZXN1bWUgcGF0aCB0aGVyZSBpcyBhbHNvIG5vIG5lZWQgdG8gYmxvY2sKPiArCQkg KiBhc3luYyBSUE0gcmVzdW1lIG9uIG91ciBzaWRlLCBzaW5jZSB0aGUgUEhZIHN5bmNocm9uaXpl cyBpdAo+ICsJCSAqIGZvciB1cy4KPiArCQkgKgo+ICsJCSAqIHBtX3J1bnRpbWVfZ2V0X2lmX2Fj dGl2ZSgpIHJldHVybnMgMCB3aGVuIHN1c3BlbmRlZCAoc2tpcCksCj4gKwkJICogMSB3aGVuIGFj dGl2ZSAocmVmIGhlbGQpLCBvciAtRUlOVkFMIHdoZW4gUE0gaXMgZGlzYWJsZWQKPiArCQkgKiAo ZGV2aWNlIGFsd2F5cyBhY3RpdmUpLiBJbiB0aGUgLUVJTlZBTCBjYXNlIFBNIHJlZiBjb3VudGlu Zwo+ICsJCSAqIGlzIGEgbm8tb3AsIHNvIHRoZSB1bmNvbmRpdGlvbmFsIHB1dCBpbiBQT1NUX1JF U0VUIGlzIHNhZmUuCj4gKwkJICovCj4gKwkJcmV0ID0gcG1fcnVudGltZV9nZXRfaWZfYWN0aXZl KGR3Yy0+ZGV2KTsKPiArCQlpZiAoIXJldCkKPiArCQkJcmV0dXJuIE5PVElGWV9PSzsKCltTZXZl cml0eTogSGlnaF0KRG9lcyB0aGlzIGNvZGUgcmlzayBhIFBNIHVzYWdlIGNvdW50ZXIgdW5kZXJm bG93IGlmIFBNIGlzIGRpc2FibGVkPwoKV2hlbiBwbV9ydW50aW1lX2dldF9pZl9hY3RpdmUoKSBy ZXR1cm5zIC1FSU5WQUwsIHRoZSAhcmV0IGNoZWNrIGV2YWx1YXRlcwp0byBmYWxzZSwgYWxsb3dp bmcgZXhlY3V0aW9uIHRvIHByb2NlZWQgd2l0aG91dCBpbmNyZW1lbnRpbmcgdGhlIHVzYWdlIGNv dW50ZXIuCgpbIC4uLiBdCj4gKwljYXNlIFBIWV9OT1RJRllfUE9TVF9SRVNFVDoKWyAuLi4gXQo+ ICsJCS8qCj4gKwkJICogRGVhc3NlcnQgUEhZIHNvZnQgcmVzZXQgdG8gcmVjb25uZWN0IHRoZSBQ SVBFIGludGVyZmFjZQo+ICsJCSAqIGFmdGVyIFBIWSByZWluaXRpYWxpemF0aW9uLgo+ICsJCSAq Lwo+ICsJCXJlZyA9IGR3YzNfcmVhZGwoZHdjLCBEV0MzX0dVU0IzUElQRUNUTChwb3J0KSk7Cj4g KwkJcmVnICY9IH5EV0MzX0dVU0IzUElQRUNUTF9QSFlTT0ZUUlNUOwo+ICsJCWR3YzNfd3JpdGVs KGR3YywgRFdDM19HVVNCM1BJUEVDVEwocG9ydCksIHJlZyk7Cj4gKwkJc3Bpbl91bmxvY2tfaXJx cmVzdG9yZSgmZHdjLT5sb2NrLCBmbGFncyk7Cj4gKwo+ICsJCXBtX3J1bnRpbWVfcHV0X2F1dG9z dXNwZW5kKGR3Yy0+ZGV2KTsKCltTZXZlcml0eTogSGlnaF0KSXMgaXQgc2FmZSB0byB1bmNvbmRp dGlvbmFsbHkgY2FsbCBwbV9ydW50aW1lX3B1dF9hdXRvc3VzcGVuZCgpIGhlcmU/CgpUaGUgY29t bWVudCBpbiBQSFlfTk9USUZZX1BSRV9SRVNFVCBzdGF0ZXMgdGhhdCBQTSByZWYgY291bnRpbmcg aXMgYSBuby1vcAppbiB0aGUgLUVJTlZBTCBjYXNlLCBidXQgcG1fcnVudGltZV9wdXRfYXV0b3N1 c3BlbmQoKSB3aWxsIGRlY3JlbWVudCB0aGUKdXNhZ2UgY291bnRlciByZWdhcmRsZXNzLiBUaGlz IGNvdWxkIGNhdXNlIGFuIHVuYmFsYW5jZWQgcHV0IGFuZCBkcm9wCnJlZmVyZW5jZXMgb3duZWQg Ynkgb3RoZXIgcGFydHMgb2YgdGhlIGRyaXZlci4KCj4gKwkJYnJlYWs7Cj4gKwl9Cj4gKwo+ICsJ cmV0dXJuIE5PVElGWV9PSzsKPiArfQo+ICsKPiArc3RhdGljIHZvaWQgZHdjM19ya19waHlfdW5y ZWdpc3Rlcl9ub3RpZmllcnModm9pZCAqZGF0YSkKPiArewo+ICsJc3RydWN0IGR3YzNfcm9ja2No aXAgKmR3Y19yayA9IGRhdGE7Cj4gKwlzdHJ1Y3QgZHdjMyAqZHdjID0gJmR3Y19yay0+ZHdjOwo+ ICsJaW50IGk7Cj4gKwo+ICsJZm9yIChpID0gMDsgaSA8IGR3Yy0+bnVtX3VzYjNfcG9ydHM7IGkr KykKPiArCQlwaHlfdW5yZWdpc3Rlcl9ub3RpZmllcihkd2MtPnVzYjNfZ2VuZXJpY19waHlbaV0s Cj4gKwkJCQkJJmR3Y19yay0+dXNiM19waHlfbmJbaV0ubmIpOwo+ICsKPiArCS8qIFJlbGVhc2Ug YW55IFBNIHJlZmVyZW5jZXMgZnJvbSBpbi1mbGlnaHQgcmVzZXRzICovCj4gKwlmb3IgKGkgPSAw OyBpIDwgZHdjLT5udW1fdXNiM19wb3J0czsgaSsrKSB7Cj4gKwkJaWYgKGR3Y19yay0+cGh5X3Jl c2V0X2FjdGl2ZSAmIEJJVChpKSkKPiArCQkJcG1fcnVudGltZV9wdXRfYXV0b3N1c3BlbmQoZHdj LT5kZXYpOwoKW1NldmVyaXR5OiBIaWdoXQpDYW4gdGhpcyBhbHNvIGNhdXNlIGEgUE0gdXNhZ2Ug Y291bnRlciB1bmRlcmZsb3c/CgpJZiBhbiBpbi1mbGlnaHQgcmVzZXQgd2FzIGluaXRpYXRlZCB3 aGlsZSBwbV9ydW50aW1lX2dldF9pZl9hY3RpdmUoKQpyZXR1cm5lZCAtRUlOVkFMLCB3ZSBkaWRu J3QgYWNxdWlyZSBhIHJlZmVyZW5jZS4gQ2FsbGluZwpwbV9ydW50aW1lX3B1dF9hdXRvc3VzcGVu ZCgpIGhlcmUgd291bGQgcmVzdWx0IGluIHRoZSBzYW1lIHVuYmFsYW5jZWQgcHV0LgoKPiArCX0K PiArCWR3Y19yay0+cGh5X3Jlc2V0X2FjdGl2ZSA9IDA7Cj4gK30KPiArCj4gK3N0YXRpYyBpbnQg ZHdjM19ya19waHlfcmVnaXN0ZXJfbm90aWZpZXJzKHN0cnVjdCBkd2MzICpkd2MpCj4gK3sKPiAr CXN0cnVjdCBkd2MzX3JvY2tjaGlwICpkd2NfcmsgPSBjb250YWluZXJfb2YoZHdjLCBzdHJ1Y3Qg ZHdjM19yb2NrY2hpcCwgZHdjKTsKPiArCWludCBpOwo+ICsKPiArCWZvciAoaSA9IDA7IGkgPCBk d2MtPm51bV91c2IzX3BvcnRzOyBpKyspIHsKPiArCQlkd2NfcmstPnVzYjNfcGh5X25iW2ldLm5i Lm5vdGlmaWVyX2NhbGwgPSBkd2MzX3VzYjNfcGh5X25vdGlmeTsKPiArCQlkd2NfcmstPnVzYjNf cGh5X25iW2ldLmR3Y19yayA9IGR3Y19yazsKPiArCQlkd2NfcmstPnVzYjNfcGh5X25iW2ldLnBv cnRfaW5kZXggPSBpOwo+ICsJCXBoeV9yZWdpc3Rlcl9ub3RpZmllcihkd2MtPnVzYjNfZ2VuZXJp Y19waHlbaV0sCj4gKwkJCQkgICAgICAmZHdjX3JrLT51c2IzX3BoeV9uYltpXS5uYik7Cj4gKwl9 Cj4gKwo+ICsJcmV0dXJuIGRldm1fYWRkX2FjdGlvbl9vcl9yZXNldChkd2MtPmRldiwgZHdjM19y a19waHlfdW5yZWdpc3Rlcl9ub3RpZmllcnMsIGR3Y19yayk7CgpbU2V2ZXJpdHk6IEhpZ2hdCkNh biBkZWZlcnJpbmcgbm90aWZpZXIgdW5yZWdpc3RyYXRpb24gdG8gdGhlIGRldnJlcyBwaGFzZSBj YXVzZSBhIGtlcm5lbApwYW5pYyBkdXJpbmcgZHJpdmVyIHVuYmluZD8KCldoZW4gdGhlIGRyaXZl ciBpcyB1bmJvdW5kLCB0aGUgRFdDMyBjb3JlIGlzIHR5cGljYWxseSBzaHV0IGRvd24gKGNsb2Nr cwpkaXNhYmxlZCBhbmQgaGFyZHdhcmUgcmVzZXQgYXNzZXJ0ZWQpIGJlZm9yZSB0aGUgZGV2cmVz IHRlYXJkb3duIHBoYXNlIHJ1bnMuCgpJZiBhbiBleHRlcm5hbCBQSFkgcmVzZXQgZXZlbnQgYXJy aXZlcyBpbiB0aGlzIHdpbmRvdywgZHdjM191c2IzX3BoeV9ub3RpZnkoKQp3b3VsZCBleGVjdXRl IGFuZCBhdHRlbXB0IHRvIHJlYWQgRFdDM19HVVNCM1BJUEVDVEwgZnJvbSB1bmNsb2NrZWQgYW5k IHJlc2V0CmhhcmR3YXJlLCBwb3RlbnRpYWxseSBjYXVzaW5nIGEgU3luY2hyb25vdXMgRXh0ZXJu YWwgQWJvcnQuCgo+ICt9CgotLSAKU2FzaGlrbyBBSSByZXZpZXcgwrcgaHR0cHM6Ly9zYXNoaWtv LmRldi8jL3BhdGNoc2V0LzIwMjYwODEzLXJvY2tjaGlwLXVzYmRwLWNsZWFudXAtdjE0LTAtYjVh ZDljNjhmYTExQGNvbGxhYm9yYS5jb20/cGFydD0zMQoKLS0gCmxpbnV4LXBoeSBtYWlsaW5nIGxp 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 4D5CA35AC12 for ; Fri, 14 Aug 2026 05:43:50 +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=1786686231; cv=none; b=cNdGkUkb7yCPBAABVb5d+vAOB1PGwGYaqLOvrrnPSLpOpKKDb2kpYUnQXp5PB5FEDYBMRakW8LR5KYzHlXw6Q9UPZbQWA6kKy37wZQPXKG0UFa3g8NZLkKSI02l0PPaNoCAYECiC510yiBALEKjZAjvPFZjOksL73jucRo6sN2g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786686231; c=relaxed/simple; bh=mYYCRnI1dNpjjwBk7lqsYX5t9jNeAX0ivrGVUhCEQp8=; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date: Message-Id; b=HgRbDHciTqJTPVgreRBxfzaS7rQ1fiPw0k2+GtAuD9nZKXFDexrVepDIa/vu4Z2oWVdL/3bBDvviy2+Yx+xLjaiHDSNPGlXzTVLjhb8MchTAa2rLj21Euq58x8nS7Vh3zFbAH+yCH8VpiyKzak6mzX8MqegynKo/yPGwx7EBkQE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=el2uGqgw; 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="el2uGqgw" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6DFEC1F000E9; Fri, 14 Aug 2026 05:43:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786686229; bh=1g6A5FvJ5WXw8UL/HnxMF3zluG9HVvl6rg26A3xq++g=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=el2uGqgwpZZJ32YdnHGPEu1NLuJTK+aCP0XEESGldgvBJ6rcNRX0VF56g+sQKYury YtigZ6De6BpHqFU4ufkM4K7qD2pMBglVtyWKAhu+n4pcQ/DXtMIHBj8Ibbe+DV8Net iH6YZY8NBCeoxKsstK2pvGpdBXNPxoqrzdsxvzITbj6QGyLqfhEiDCZLEcyYSVcF34 66/H6Gpovqc4I9WqUa/bE7eJaTOAlGzIURGBE8RtZpBo+s/XCbI80/H6EnFpw5SPjn ZHnNVUTAp8mTdwP2//UDmKIUhmMGNHDL7d5C/FOwxbaHQ6Jpg+wRzyVquuT5Gyqi9M YXQTF3lfirtpQ== From: sashiko-bot@kernel.org Subject: Re: [PATCH v14 31/38] usb: dwc3: rockchip: support PHY reset notifications Reply-To: sashiko-reviews@lists.linux.dev To: "Sebastian Reichel" Cc: robh@kernel.org, devicetree@vger.kernel.org, olteanv@gmail.com, vkoul@kernel.org, linux-phy@lists.infradead.org, neil.armstrong@linaro.org, conor+dt@kernel.org In-Reply-To: <20260813-rockchip-usbdp-cleanup-v14-31-b5ad9c68fa11@collabora.com> References: <20260813-rockchip-usbdp-cleanup-v14-0-b5ad9c68fa11@collabora.com> <20260813-rockchip-usbdp-cleanup-v14-31-b5ad9c68fa11@collabora.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Fri, 14 Aug 2026 05:43:48 +0000 Message-Id: <20260814054349.6DFEC1F000E9@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: - [High] The PHY notification handler unconditionally drops a PM usage refe= rence if `pm_runtime_get_if_active()` returns `-EINVAL`, causing a usage co= unter underflow and potentially dropping references owned by other parts of= the driver. - [High] The PHY notifier unregistration is deferred to the devres teardown= phase, creating a race condition where an asynchronous PHY reset event acc= esses unclocked and reset DWC3 hardware, causing a kernel panic. -- --- Patch [31]: [PATCH v14 31/38] usb: dwc3: rockchip: support PHY reset no= tifications --- commit f458b4c213899f50f1d40c52f7c5aaeb38fdb675 Author: Sebastian Reichel usb: dwc3: rockchip: support PHY reset notifications On recent Rockchip platforms (at least RK3588 & RK3576), DWC3 IP is used with a USBDP PHY providing USB3 and DP. This PHY needs to be reset when the mode changes, which may happen when plugging in different USB-C devices. This adds handling for the new PHY framework reset notifications. > diff --git a/drivers/usb/dwc3/dwc3-rockchip.c b/drivers/usb/dwc3/dwc3-roc= kchip.c > index 1df33625b69f8..9e91e5f7e53d6 100644 > --- a/drivers/usb/dwc3/dwc3-rockchip.c > +++ b/drivers/usb/dwc3/dwc3-rockchip.c [ ... ] > +static int dwc3_usb3_phy_notify(struct notifier_block *nb, > + unsigned long action, void *data) > +{ [ ... ] > + switch (action) { > + case PHY_NOTIFY_PRE_RESET: > + /* > + * If already suspended, the resume path will reinit GUSB3PIPECTL > + * via dwc3_core_init(). A forced resume is not possible as that > + * would call phy_init() resulting in a deadlock. Due to the > + * phy_init() in the resume path there is also no need to block > + * async RPM resume on our side, since the PHY synchronizes it > + * for us. > + * > + * pm_runtime_get_if_active() returns 0 when suspended (skip), > + * 1 when active (ref held), or -EINVAL when PM is disabled > + * (device always active). In the -EINVAL case PM ref counting > + * is a no-op, so the unconditional put in POST_RESET is safe. > + */ > + ret =3D pm_runtime_get_if_active(dwc->dev); > + if (!ret) > + return NOTIFY_OK; [Severity: High] Does this code risk a PM usage counter underflow if PM is disabled? When pm_runtime_get_if_active() returns -EINVAL, the !ret check evaluates to false, allowing execution to proceed without incrementing the usage coun= ter. [ ... ] > + case PHY_NOTIFY_POST_RESET: [ ... ] > + /* > + * Deassert PHY soft reset to reconnect the PIPE interface > + * after PHY reinitialization. > + */ > + reg =3D dwc3_readl(dwc, DWC3_GUSB3PIPECTL(port)); > + reg &=3D ~DWC3_GUSB3PIPECTL_PHYSOFTRST; > + dwc3_writel(dwc, DWC3_GUSB3PIPECTL(port), reg); > + spin_unlock_irqrestore(&dwc->lock, flags); > + > + pm_runtime_put_autosuspend(dwc->dev); [Severity: High] Is it safe to unconditionally call pm_runtime_put_autosuspend() here? The comment in PHY_NOTIFY_PRE_RESET states that PM ref counting is a no-op in the -EINVAL case, but pm_runtime_put_autosuspend() will decrement the usage counter regardless. This could cause an unbalanced put and drop references owned by other parts of the driver. > + break; > + } > + > + return NOTIFY_OK; > +} > + > +static void dwc3_rk_phy_unregister_notifiers(void *data) > +{ > + struct dwc3_rockchip *dwc_rk =3D data; > + struct dwc3 *dwc =3D &dwc_rk->dwc; > + int i; > + > + for (i =3D 0; i < dwc->num_usb3_ports; i++) > + phy_unregister_notifier(dwc->usb3_generic_phy[i], > + &dwc_rk->usb3_phy_nb[i].nb); > + > + /* Release any PM references from in-flight resets */ > + for (i =3D 0; i < dwc->num_usb3_ports; i++) { > + if (dwc_rk->phy_reset_active & BIT(i)) > + pm_runtime_put_autosuspend(dwc->dev); [Severity: High] Can this also cause a PM usage counter underflow? If an in-flight reset was initiated while pm_runtime_get_if_active() returned -EINVAL, we didn't acquire a reference. Calling pm_runtime_put_autosuspend() here would result in the same unbalanced put. > + } > + dwc_rk->phy_reset_active =3D 0; > +} > + > +static int dwc3_rk_phy_register_notifiers(struct dwc3 *dwc) > +{ > + struct dwc3_rockchip *dwc_rk =3D container_of(dwc, struct dwc3_rockchip= , dwc); > + int i; > + > + for (i =3D 0; i < dwc->num_usb3_ports; i++) { > + dwc_rk->usb3_phy_nb[i].nb.notifier_call =3D dwc3_usb3_phy_notify; > + dwc_rk->usb3_phy_nb[i].dwc_rk =3D dwc_rk; > + dwc_rk->usb3_phy_nb[i].port_index =3D i; > + phy_register_notifier(dwc->usb3_generic_phy[i], > + &dwc_rk->usb3_phy_nb[i].nb); > + } > + > + return devm_add_action_or_reset(dwc->dev, dwc3_rk_phy_unregister_notifi= ers, dwc_rk); [Severity: High] Can deferring notifier unregistration to the devres phase cause a kernel panic during driver unbind? When the driver is unbound, the DWC3 core is typically shut down (clocks disabled and hardware reset asserted) before the devres teardown phase runs. If an external PHY reset event arrives in this window, dwc3_usb3_phy_notify= () would execute and attempt to read DWC3_GUSB3PIPECTL from unclocked and reset hardware, potentially causing a Synchronous External Abort. > +} --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260813-rockchip-u= sbdp-cleanup-v14-0-b5ad9c68fa11@collabora.com?part=3D31