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 C2DE5C44501 for ; Thu, 9 Jul 2026 19:21:27 +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=rIvHwNEwTq/l0ejcqtucO/SvlFrd8WpndGd8CxBiB8g=; b=epq/Y7/gvPe26N iVi21XEXN/a+pBZ9TmyJjzSGqpYw+Uw6poL+bGuH2GHKq8Bu59jLgEGnDXflCbXJMFa1v01CihjnY x1N88AxRsOXzMn33xANVkKblvD/dFpghn+CIUb117ohH/bt6/FSOt6xl5KSXEkuE3gT18m3VvFdzm FByeSXp55bCKcxQgfKGM4sMltxAHw07G0glkcbpxectR1apY/vOmE4gDfwaKHsyHgDGH8+IOXUT/b E0cEATLAJ7kSWDc1kOIsGWrRuiuP6tR7/usWQCPsriT43eIFGTfmDAwp20ck6kA66AF2VVAj/Au3Q GlLQxq9fkdNVEQtmt1qA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1whuJL-00000003Rwn-2HJh; Thu, 09 Jul 2026 19:21:27 +0000 Received: from sea.source.kernel.org ([172.234.252.31]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1whuJK-00000003RwZ-0yun for linux-phy@lists.infradead.org; Thu, 09 Jul 2026 19:21:26 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 02D0542AFE; Thu, 9 Jul 2026 19:21:26 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 72CF61F000E9; Thu, 9 Jul 2026 19:21:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783624885; bh=DNmTkwcBnzxTjrCC37k0A/W6iNdJ5fj0ljG7c/dbdOI=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=JMkckb6/JrcIauEbAPjA47PSq7j3Vl31AMiKfaKcZcVQf3a7+j8b/zLEq+DDpxoXT 8EfI5kFv4vskHeWH7g1Ih9onaYLCKcc519gX/ZuwXIjMjbc1udo72t6X95x8Uyz+e4 OMk5ZX9R7C2zN7v/854sKCjbqnh3kEcvqVI6L6x1iK2uayWbNkDpAUATLBjXwrQQkC Zj5vaQyHvxIF7KHiucZGdOeZbX9khtOcQSt8EL7HmXmnSLnS5JuG35p38k94M3q4Go 6bAhCY1svDLQ/eje5BKEylN9gfaQo9UlV8eNU1+bMU68qlhy17zBs8r9es6Q0KKzKJ Ng6H25UTZITZQ== From: sashiko-bot@kernel.org Subject: Re: [PATCH v11 12/36] phy: rockchip: usbdp: Limit DP lane count to muxed lanes To: "Sebastian Reichel" Cc: neil.armstrong@linaro.org, robh@kernel.org, conor+dt@kernel.org, devicetree@vger.kernel.org, olteanv@gmail.com, linux-phy@lists.infradead.org, vkoul@kernel.org In-Reply-To: <20260709-rockchip-usbdp-cleanup-v11-12-a149ac60f76c@collabora.com> References: <20260709-rockchip-usbdp-cleanup-v11-0-a149ac60f76c@collabora.com> <20260709-rockchip-usbdp-cleanup-v11-12-a149ac60f76c@collabora.com> Date: Thu, 09 Jul 2026 19:21:25 +0000 Message-Id: <20260709192125.72CF61F000E9@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 IFtIaWdoXSBUaGUgRFAgbGFuZSBib3VuZHMgY2hlY2sgYW5kIFBIWSBjb25maWd1cmF0aW9uIGV4 ZWN1dGUgd2l0aG91dCBob2xkaW5nIHRoZSBkcml2ZXIncyBtdXRleCwgY3JlYXRpbmcgYSBUT0NU T1UgcmFjZSBjb25kaXRpb24gd2l0aCBjb25jdXJyZW50IFR5cGUtQyBldmVudHMuCi0gW0hpZ2hd IFRoZSBuZXdseSBhZGRlZCBsYW5lIGNvdW50IGNoZWNrIGlzIGJ5cGFzc2VkIGR1cmluZyBzdGFu ZGFsb25lIERQIHZvbHRhZ2UgdXBkYXRlcywgYWxsb3dpbmcgdGhlIHNhbWUgVVNCMyByZWdpc3Rl ciBjb3JydXB0aW9uIHRoZSBwYXRjaCBpbnRlbmRlZCB0byBmaXguCi0tCgotLS0gUGF0Y2ggWzEy XTogW1BBVENIIHYxMSAxMi8zNl0gcGh5OiByb2NrY2hpcDogdXNiZHA6IExpbWl0IERQIGxhbmUg Y291bnQgdG8gbXV4ZWQgbGFuZXMgLS0tCmNvbW1pdCA0MmZkMDI1NjVmMWMxMzhjOGZhZWUyNWQ1 ZmQ5MjljZWIwZjJlN2UzCkF1dGhvcjogU2ViYXN0aWFuIFJlaWNoZWwgPHNlYmFzdGlhbi5yZWlj aGVsQGNvbGxhYm9yYS5jb20+ClN1YmplY3Q6IHBoeTogcm9ja2NoaXA6IHVzYmRwOiBMaW1pdCBE UCBsYW5lIGNvdW50IHRvIG11eGVkIGxhbmVzCgpUaGlzIHBhdGNoIGFkZHMgYSBjaGVjayB0byBs aW1pdCB0aGUgRGlzcGxheVBvcnQgbGFuZSBjb3VudCB0byB0aGUgbXV4ZWQKbGFuZXMsIHByZXZl bnRpbmcgdGhlIERQIGNvbnRyb2xsZXIgZnJvbSBjb25maWd1cmluZyA0IGxhbmVzIHdoZW4gdGhl IFBIWQppcyByZXN0cmljdGVkIHRvIDIgbGFuZXMuIFRoaXMgYWltcyB0byBwcm90ZWN0IFVTQjMg dXNhZ2UgZnJvbSBiZWluZwpjb3JydXB0ZWQgYnkgaW5jb3JyZWN0IHZvbHRhZ2UgY29uZmlndXJh dGlvbnMuCgpMaW5rOiBodHRwczovL2xvcmUua2VybmVsLm9yZy9saW51eC1waHkvMjAyNjA2MTIx NjU1NDYuOThFMUYxRjAwMEU5QHNtdHAua2VybmVsLm9yZy8KCj4gZGlmZiAtLWdpdCBhL2RyaXZl cnMvcGh5L3JvY2tjaGlwL3BoeS1yb2NrY2hpcC11c2JkcC5jIGIvZHJpdmVycy9waHkvcm9ja2No aXAvcGh5LXJvY2tjaGlwLXVzYmRwLmMKPiBpbmRleCBjNGQ2MmIyMzRlYTgwLi5iMTcyY2U2YTcy MmVlIDEwMDY0NAo+IC0tLSBhL2RyaXZlcnMvcGh5L3JvY2tjaGlwL3BoeS1yb2NrY2hpcC11c2Jk cC5jCj4gKysrIGIvZHJpdmVycy9waHkvcm9ja2NoaXAvcGh5LXJvY2tjaGlwLXVzYmRwLmMKPiBA QCAtMTA5OSw2ICsxMDk5LDkgQEAgc3RhdGljIGludCBya191ZHBoeV9kcF9waHlfdmVyaWZ5X2xp bmtfcmF0ZShzdHJ1Y3QgcmtfdWRwaHkgKnVkcGh5LAo+ICBzdGF0aWMgaW50IHJrX3VkcGh5X2Rw X3BoeV92ZXJpZnlfbGFuZXMoc3RydWN0IHJrX3VkcGh5ICp1ZHBoeSwKPiAgCQkJCQlzdHJ1Y3Qg cGh5X2NvbmZpZ3VyZV9vcHRzX2RwICpkcCkKPiAgewo+ICsJaWYgKGRwLT5sYW5lcyA+IHVkcGh5 LT5kcF9sYW5lcykKPiArCQlyZXR1cm4gLUVJTlZBTDsKPiArCgpbU2V2ZXJpdHk6IEhpZ2hdClRo aXMgaXMgYSBwcmUtZXhpc3RpbmcgaXNzdWUsIGJ1dCBkb2VzIHRoaXMgYm91bmRzIGNoZWNrIG5l ZWQgdG8gYmUKcHJvdGVjdGVkIGJ5IGEgbG9jaz8KCklmIGEgVHlwZS1DIGV2ZW50IChsaWtlIGEg Y2FibGUgZmxpcCByZWR1Y2luZyBEUCBsYW5lcyBmcm9tIDQgdG8gMikKb2NjdXJzIGNvbmN1cnJl bnRseSB3aXRoIGEgRFAgbGluayB0cmFpbmluZyBvcGVyYXRpb24sIGNvdWxkIHRoZSBib3VuZHMK Y2hlY2sgcGFzcyB3aGlsZSB1ZHBoeS0+ZHBfbGFuZXMgaXMgND8KCklmIGEgY29udGV4dCBzd2l0 Y2ggYWxsb3dzIHRoZSBUeXBlLUMgaGFuZGxlciB0byByZWR1Y2UgdGhlIGxhbmUgY291bnQKYW5k IGNoYW5nZSB1ZHBoeS0+bGFuZV9tdXhfc2VsIHdoaWxlIGhvbGRpbmcgdWRwaHktPm11dGV4LCB3 aGVuIHRoaXMKdGhyZWFkIHJlc3VtZXMgYW5kIHByb2NlZWRzIHRvIHJrX3VkcGh5X2RwX3BoeV9j b25maWd1cmUoKSAod2hpY2ggaXMKY2FsbGVkIHdpdGhvdXQgaG9sZGluZyB1ZHBoeS0+bXV0ZXgp LCBjb3VsZCBpdCBvdmVyd3JpdGUgaGFyZHdhcmUKcmVnaXN0ZXJzIG9mIHBoeXNpY2FsIGxhbmVz IG5vdyBhc3NpZ25lZCB0byBVU0IzOgoKcmtfdWRwaHlfZHBfcGh5X2NvbmZpZ3VyZSgpIHsKICAg IC4uLgogICAgbGFuZSA9IHVkcGh5LT5kcF9sYW5lX3NlbFtpXTsKICAgIC4uLgogICAgcmVnbWFw X3VwZGF0ZV9iaXRzKHVkcGh5LT5wbWFfcmVnbWFwLAogICAgICAgICAgICAgICAgICAgICAgIFRS U1ZfQU5BX1RYX0NMS19PRkZTRVRfTihsYW5lKSwKICAgICAgICAgICAgICAgICAgICAgICBMTl9B TkFfVFhfU0VSX1RYQ0xLX0lOViwKICAgICAgICAgICAgICAgICAgICAgICBGSUVMRF9QUkVQKExO X0FOQV9UWF9TRVJfVFhDTEtfSU5WLAogICAgICAgICAgICAgICAgICAgICAgIHVkcGh5LT5sYW5l X211eF9zZWxbbGFuZV0pKTsKICAgIC4uLgp9CgpbU2V2ZXJpdHk6IEhpZ2hdClRoaXMgaXMgYWxz byBhIHByZS1leGlzdGluZyBpc3N1ZSwgYnV0IHdpbGwgdGhpcyBjaGVjayBiZSBieXBhc3NlZApk dXJpbmcgc3RhbmRhbG9uZSBEUCB2b2x0YWdlIHVwZGF0ZXM/CgpJZiBhIFR5cGUtQyBldmVudCBh c3luY2hyb25vdXNseSByZWR1Y2VzIHVkcGh5LT5kcF9sYW5lcyAoZS5nLiwgZnJvbQo0IGRvd24g dG8gMiksIGFuZCB0aGUgRFAgY29udHJvbGxlciBzdWJzZXF1ZW50bHkgaXNzdWVzIGEgc3RhbmRh bG9uZQp2b2x0YWdlIHVwZGF0ZSAod2hlcmUgZHAtPnNldF92b2x0YWdlcz0xIGFuZCBkcC0+c2V0 X2xhbmVzPTApIHByaW9yIHRvCmEgZnVsbCBsaW5rIHJldHJhaW46Cgpya191ZHBoeV9kcF9waHlf Y29uZmlndXJlKCkgewogICAgLi4uCiAgICBpZiAoZHAtPnNldF9sYW5lcykgewogICAgICAgIHJl dCA9IHJrX3VkcGh5X2RwX3BoeV92ZXJpZnlfbGFuZXModWRwaHksIGRwKTsKICAgICAgICBpZiAo cmV0KQogICAgICAgICAgICByZXR1cm4gcmV0OwogICAgfQogICAgLi4uCn0KCldvdWxkIHJrX3Vk cGh5X2RwX3BoeV92ZXJpZnlfbGFuZXMoKSBiZSBieXBhc3NlZCBlbnRpcmVseT8gVGhpcyB3b3Vs ZAphbGxvdyB0aGUgY29uZmlndXJhdGlvbiBsb29wIHRvIGl0ZXJhdGUgdXAgdG8gdGhlIHN0YWxl IGNhY2hlZAp1ZHBoeS0+bGFuZXMgbGltaXQ6Cgpya191ZHBoeV9kcF9waHlfY29uZmlndXJlKCkg ewogICAgLi4uCiAgICBmb3IgKGkgPSAwOyBpIDwgdWRwaHktPmxhbmVzOyBpKyspIHsKICAgIC4u LgoKYW5kIHBvdGVudGlhbGx5IGNhdXNlIHRoZSBvdXQtb2YtYm91bmRzIHdyaXRlcyB0byB0aGUg VVNCMyBoYXJkd2FyZQpyZWdpc3RlcnMgdGhhdCB0aGlzIHBhdGNoIGludGVuZHMgdG8gcHJldmVu dC4KCj4gIAlzd2l0Y2ggKGRwLT5sYW5lcykgewo+ICAJY2FzZSAxOgo+ICAJY2FzZSAyOgoKLS0g ClNhc2hpa28gQUkgcmV2aWV3IMK3IGh0dHBzOi8vc2FzaGlrby5kZXYvIy9wYXRjaHNldC8yMDI2 MDcwOS1yb2NrY2hpcC11c2JkcC1jbGVhbnVwLXYxMS0wLWExNDlhYzYwZjc2Y0Bjb2xsYWJvcmEu Y29tP3BhcnQ9MTIKCi0tIApsaW51eC1waHkgbWFpbGluZyBsaXN0CmxpbnV4LXBoeUBsaXN0cy5p bmZyYWRlYWQub3JnCmh0dHBzOi8vbGlzdHMuaW5mcmFkZWFkLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2xpbnV4LXBoeQo= 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 8F6253AFAF4 for ; Thu, 9 Jul 2026 19:21:25 +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=1783624887; cv=none; b=CRQZdJ40oqk46J22fEAzY6JqQ9gssOpbiT1Wr0Wy86yfI3zJLQQR7Wl39ThPrrIwz/EyzYOmDnFXsVOU1mG53gyYR7IZGf+CKMtN6gCE2Ijjz9ZIAxvcvQ4Mvu3Y7p56WVrkBKN1rMP9n9vqi0vzbkKCghHAM4D1M0WkkkPGXs8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783624887; c=relaxed/simple; bh=uGX6CTXfGlcrEjhdPRwZDWJw0v/HJ1cjCQzNxOjhUyY=; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date: Message-Id; b=DR54ajIRD3B10rsM3pfU9KA/P1BLNAAQ9cmehfABDAnOqwBd/537Oezoaag6z9FINag+GFsbgAyI/sqDR0xVoxAzCm+HO0U6SecQ6tTiiNEYKbYCZH5pssTIayKdB7h6xiwmwlt7UXQSdYRKyx4bDjhNvpm3GPBTHEwZ6220LF4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=JMkckb6/; 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="JMkckb6/" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 72CF61F000E9; Thu, 9 Jul 2026 19:21:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783624885; bh=DNmTkwcBnzxTjrCC37k0A/W6iNdJ5fj0ljG7c/dbdOI=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=JMkckb6/JrcIauEbAPjA47PSq7j3Vl31AMiKfaKcZcVQf3a7+j8b/zLEq+DDpxoXT 8EfI5kFv4vskHeWH7g1Ih9onaYLCKcc519gX/ZuwXIjMjbc1udo72t6X95x8Uyz+e4 OMk5ZX9R7C2zN7v/854sKCjbqnh3kEcvqVI6L6x1iK2uayWbNkDpAUATLBjXwrQQkC Zj5vaQyHvxIF7KHiucZGdOeZbX9khtOcQSt8EL7HmXmnSLnS5JuG35p38k94M3q4Go 6bAhCY1svDLQ/eje5BKEylN9gfaQo9UlV8eNU1+bMU68qlhy17zBs8r9es6Q0KKzKJ Ng6H25UTZITZQ== From: sashiko-bot@kernel.org Subject: Re: [PATCH v11 12/36] phy: rockchip: usbdp: Limit DP lane count to muxed lanes Reply-To: sashiko-reviews@lists.linux.dev To: "Sebastian Reichel" Cc: neil.armstrong@linaro.org, robh@kernel.org, conor+dt@kernel.org, devicetree@vger.kernel.org, olteanv@gmail.com, linux-phy@lists.infradead.org, vkoul@kernel.org In-Reply-To: <20260709-rockchip-usbdp-cleanup-v11-12-a149ac60f76c@collabora.com> References: <20260709-rockchip-usbdp-cleanup-v11-0-a149ac60f76c@collabora.com> <20260709-rockchip-usbdp-cleanup-v11-12-a149ac60f76c@collabora.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Thu, 09 Jul 2026 19:21:25 +0000 Message-Id: <20260709192125.72CF61F000E9@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 DP lane bounds check and PHY configuration execute without hol= ding the driver's mutex, creating a TOCTOU race condition with concurrent T= ype-C events. - [High] The newly added lane count check is bypassed during standalone DP = voltage updates, allowing the same USB3 register corruption the patch inten= ded to fix. -- --- Patch [12]: [PATCH v11 12/36] phy: rockchip: usbdp: Limit DP lane count= to muxed lanes --- commit 42fd02565f1c138c8faee25d5fd929ceb0f2e7e3 Author: Sebastian Reichel Subject: phy: rockchip: usbdp: Limit DP lane count to muxed lanes This patch adds a check to limit the DisplayPort lane count to the muxed lanes, preventing the DP controller from configuring 4 lanes when the PHY is restricted to 2 lanes. This aims to protect USB3 usage from being corrupted by incorrect voltage configurations. Link: https://lore.kernel.org/linux-phy/20260612165546.98E1F1F000E9@smtp.ke= rnel.org/ > diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rock= chip/phy-rockchip-usbdp.c > index c4d62b234ea80..b172ce6a722ee 100644 > --- a/drivers/phy/rockchip/phy-rockchip-usbdp.c > +++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c > @@ -1099,6 +1099,9 @@ static int rk_udphy_dp_phy_verify_link_rate(struct = rk_udphy *udphy, > static int rk_udphy_dp_phy_verify_lanes(struct rk_udphy *udphy, > struct phy_configure_opts_dp *dp) > { > + if (dp->lanes > udphy->dp_lanes) > + return -EINVAL; > + [Severity: High] This is a pre-existing issue, but does this bounds check need to be protected by a lock? If a Type-C event (like a cable flip reducing DP lanes from 4 to 2) occurs concurrently with a DP link training operation, could the bounds check pass while udphy->dp_lanes is 4? If a context switch allows the Type-C handler to reduce the lane count and change udphy->lane_mux_sel while holding udphy->mutex, when this thread resumes and proceeds to rk_udphy_dp_phy_configure() (which is called without holding udphy->mutex), could it overwrite hardware registers of physical lanes now assigned to USB3: rk_udphy_dp_phy_configure() { ... lane =3D udphy->dp_lane_sel[i]; ... regmap_update_bits(udphy->pma_regmap, TRSV_ANA_TX_CLK_OFFSET_N(lane), LN_ANA_TX_SER_TXCLK_INV, FIELD_PREP(LN_ANA_TX_SER_TXCLK_INV, udphy->lane_mux_sel[lane])); ... } [Severity: High] This is also a pre-existing issue, but will this check be bypassed during standalone DP voltage updates? If a Type-C event asynchronously reduces udphy->dp_lanes (e.g., from 4 down to 2), and the DP controller subsequently issues a standalone voltage update (where dp->set_voltages=3D1 and dp->set_lanes=3D0) prior to a full link retrain: rk_udphy_dp_phy_configure() { ... if (dp->set_lanes) { ret =3D rk_udphy_dp_phy_verify_lanes(udphy, dp); if (ret) return ret; } ... } Would rk_udphy_dp_phy_verify_lanes() be bypassed entirely? This would allow the configuration loop to iterate up to the stale cached udphy->lanes limit: rk_udphy_dp_phy_configure() { ... for (i =3D 0; i < udphy->lanes; i++) { ... and potentially cause the out-of-bounds writes to the USB3 hardware registers that this patch intends to prevent. > switch (dp->lanes) { > case 1: > case 2: --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260709-rockchip-u= sbdp-cleanup-v11-0-a149ac60f76c@collabora.com?part=3D12