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 B8501347535 for ; Fri, 10 Jul 2026 21:07:41 +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=1783717662; cv=none; b=trywSruzuGcJvLWN4rDktAkTc+100CCMEpn7GfvWWmRx6SwuJMmTaN6Xk6x7VQIbt57bK+qjVAqU9wDjKzp40wXsjiyEpdLXqHPsMdKrKheOfuFkDpsWkJ66Q/0STkgjre1yK5SWsbUP4+tcMgd31CCnwvzZtymEWYXee0sPbzM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783717662; c=relaxed/simple; bh=QbkEWasvGFkqS7MDUh5Dif7zSSUTlgT56lHXHZjUDjY=; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date: Message-Id; b=RiwXCrRuAb+ZAon+YBmQRa3xaljG0I4mcG/YaooXvrMJhzdocjtyBpjoRucY0qYKtz2pAODKE/FR6ZzhMaI+e+Rfzlq1pYJTeOUPdtBxXSDVy3gCGSzLJeDcbXXEhfe2TEi3xbpzTIrLKsLtKnYVU8alJEhKowVr+gMT0mZ2EcU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=LdmG1IgP; 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="LdmG1IgP" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 02D761F000E9; Fri, 10 Jul 2026 21:07:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783717661; bh=OjDT+XU08SbkEiLzCZ3Sp0g2d4xORNwQTRirAqxonvE=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=LdmG1IgPddPqXFjlEboNzWU6K6Cbgw76Ywc3mThJmOwHB64zEV9R+vHxfAaAubMSl ZUlrnrNHu6ZB2XHhH/tWlLIQtrXAXyzBjrf9sQrMgz6aKP84GuEnT7bgLe2pyDLbyY mp4KnTZTorDnyqg2Q81wQBqFdqkSMaXS2HJ2XKAgQMfVnzBSpzkIsadEw/FG2sR3V0 DGEJ1Qe6vCGgd7xOD+Bs+8bq+ZZz/+K4yB9rj+lkjYoLDer2eZeUGf23M24SDmPwP+ oW1A/dI1piVEGKuHOxOQ43y0aKv6r/1vigHHFqIUelCZQLW7mN/0CwAjyg4xELHAMl SpH7lfqfU/cmw== From: sashiko-bot@kernel.org Subject: Re: [PATCH v12 03/36] phy: rockchip: usbdp: Do not lose USB3 PHY status Reply-To: sashiko-reviews@lists.linux.dev To: "Sebastian Reichel" Cc: linux-phy@lists.infradead.org, olteanv@gmail.com, devicetree@vger.kernel.org, conor+dt@kernel.org, robh@kernel.org, vkoul@kernel.org, neil.armstrong@linaro.org In-Reply-To: <20260710-rockchip-usbdp-cleanup-v12-3-8b41a9a9bef0@collabora.com> References: <20260710-rockchip-usbdp-cleanup-v12-0-8b41a9a9bef0@collabora.com> <20260710-rockchip-usbdp-cleanup-v12-3-8b41a9a9bef0@collabora.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Fri, 10 Jul 2026 21:07:40 +0000 Message-Id: <20260710210741.02D761F000E9@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 3 potential issue(= s) to consider: New issues: - [High] Removing the clearance of `udphy->status` introduces unbalanced cl= ock disables and repeated hardware teardowns on the `rk_udphy_setup()` erro= r path. Pre-existing issues: - [High] Missing mutex acquisition in `rk_udphy_dp_phy_configure` leads to = data races on shared driver state. - [High] Incomplete handling of mode transitions causes DWC3 SErrors and pe= rmanently breaks the USB3 data stream. -- --- Patch [3]: [PATCH v12 03/36] phy: rockchip: usbdp: Do not lose USB3 PHY= status --- commit efe9bcb0d6328640e43461f982816e45f55f9a36 Author: Sebastian Reichel phy: rockchip: usbdp: Do not lose USB3 PHY status By default (i.e. without manually enabling runtime PM) DWC3 requests the USB3 PHY once and keeps it enabled all the time. When DisplayPort is being requested later on, a mode change is needed. This re-initializes the PHY. During re-initialization the status variable has incorrectly been cleared, which means the tracking information for USB3 is lost. This is not an immediate problem, since the DP side keeps the PHY enabled. But once DP is toggled off, the whole PHY will be disabled. This is a problem, because the USB side still needs it powered. Fix things by not clearing the status flags. > diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rock= chip/phy-rockchip-usbdp.c > index a5ffdf7a6e76b..12dfdd470a782 100644 > --- a/drivers/phy/rockchip/phy-rockchip-usbdp.c > +++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c > @@ -1008,7 +1008,6 @@ static int rk_udphy_power_on(struct rk_udphy *udphy= , u8 mode) > rk_udphy_u3_port_disable(udphy, false); > udphy->mode_change =3D false; > } else if (udphy->mode_change) { [Severity: High] This is a pre-existing issue, but I have a question about how the mode transitions are handled here in rk_udphy_power_on(). When Type-C negotiation changes the mode to UDPHY_MODE_DP_USB, the driver skips calling rk_udphy_u3_port_disable(udphy, true). It then cuts the PHY clocks via rk_udphy_disable() while the DWC3 controller might still be active. Can this cause System Errors (SErrors) from the DWC3 controller? Additionally, if the old mode was UDPHY_MODE_DP, the USB3 port is disabled but never re-enabled after rk_udphy_setup() succeeds. Does this leave the USB3 data stream permanently broken in the GRF registers? > - udphy->status =3D UDPHY_MODE_NONE; > if (udphy->mode =3D=3D UDPHY_MODE_DP) > rk_udphy_u3_port_disable(udphy, true); > =20 > rk_udphy_disable(udphy); > ret =3D rk_udphy_setup(udphy); > if (ret) > return ret; [Severity: High] Since this clearance is removed, what happens if rk_udphy_setup() fails immediately after this block? If rk_udphy_setup() returns an error, the function exits without updating udphy->status to reflect that the hardware was actually disabled by rk_udphy_disable() just above. Could this lead to unbalanced clock disables and repeated resets later when phy_power_off() or phy_power_on() is called, since the driver still assumes the PHY is active? [ ... ] [Severity: High] This is a pre-existing issue, but does rk_udphy_dp_phy_configure() need to hold udphy->mutex when accessing shared driver state? Looking at drivers/phy/rockchip/phy-rockchip-usbdp.c: rk_udphy_dp_phy_configure() { struct rk_udphy *udphy =3D phy_get_drvdata(phy); ... if (dp->set_voltages) { for (i =3D 0; i < udphy->lanes; i++) { lane =3D udphy->dp_lane_sel[i]; ... This function reads udphy->dp_lane_sel, udphy->lanes, and udphy->lane_mux_sel without acquiring the mutex. Meanwhile, if a Type-C orientation flip occurs, rk_udphy_orien_sw_set() acquires the mutex and mutates this exact state: rk_udphy_orien_sw_set() { ... mutex_lock(&udphy->mutex); ... udphy->flip =3D orien =3D=3D TYPEC_ORIENTATION_REVERSE; rk_udphy_set_typec_default_mapping(udphy); ... Can this data race cause voltages to be programmed to the wrong PHY lanes, leading to DP link training failures if a cable is flipped during active DisplayPort use? --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260710-rockchip-u= sbdp-cleanup-v12-0-8b41a9a9bef0@collabora.com?part=3D3 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 B068AC43458 for ; Fri, 10 Jul 2026 21:07:43 +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=x5f7MD1oBDuM+quM7zvG/FLEyMBSg8m6ZZD22g8cd1g=; b=cvWJauGc2BXAkL HRogmgQcmPo/KLJYSLOZbEnuVrUlNdYRp+ybVG5OJVNdR53UXJPQg04S//h+KuBCaFESQlNin0l9y PwQiNdPr6Jgx3iRndFj9ABS1hpHSM6DUV2J+WbUhrBxs5cSklRsA79442z6nAgPFWccFDY/e+YnMi zkk5GXHuJ3so9eRzeFgxGhU3J2/cj6RLqJUK2DVhDj3hpcyFYfhPRa5wghwCquFoncpsL/DBDA2Bi FQPoPZ1zq+ECZkPbmlN816PQ3irOOplYFv63jHKXyTFNnqjilRiYC5JS0TPch/pgdiaGVVgjHlOiM CpDWCtACF54a/4NlyAKg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wiIRj-00000005lZ0-20Lo; Fri, 10 Jul 2026 21:07:43 +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 1wiIRi-00000005lYW-2JXl for linux-phy@lists.infradead.org; Fri, 10 Jul 2026 21:07:42 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id B134460051; Fri, 10 Jul 2026 21:07:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 02D761F000E9; Fri, 10 Jul 2026 21:07:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783717661; bh=OjDT+XU08SbkEiLzCZ3Sp0g2d4xORNwQTRirAqxonvE=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=LdmG1IgPddPqXFjlEboNzWU6K6Cbgw76Ywc3mThJmOwHB64zEV9R+vHxfAaAubMSl ZUlrnrNHu6ZB2XHhH/tWlLIQtrXAXyzBjrf9sQrMgz6aKP84GuEnT7bgLe2pyDLbyY mp4KnTZTorDnyqg2Q81wQBqFdqkSMaXS2HJ2XKAgQMfVnzBSpzkIsadEw/FG2sR3V0 DGEJ1Qe6vCGgd7xOD+Bs+8bq+ZZz/+K4yB9rj+lkjYoLDer2eZeUGf23M24SDmPwP+ oW1A/dI1piVEGKuHOxOQ43y0aKv6r/1vigHHFqIUelCZQLW7mN/0CwAjyg4xELHAMl SpH7lfqfU/cmw== From: sashiko-bot@kernel.org Subject: Re: [PATCH v12 03/36] phy: rockchip: usbdp: Do not lose USB3 PHY status To: "Sebastian Reichel" Cc: linux-phy@lists.infradead.org, olteanv@gmail.com, devicetree@vger.kernel.org, conor+dt@kernel.org, robh@kernel.org, vkoul@kernel.org, neil.armstrong@linaro.org In-Reply-To: <20260710-rockchip-usbdp-cleanup-v12-3-8b41a9a9bef0@collabora.com> References: <20260710-rockchip-usbdp-cleanup-v12-0-8b41a9a9bef0@collabora.com> <20260710-rockchip-usbdp-cleanup-v12-3-8b41a9a9bef0@collabora.com> Date: Fri, 10 Jul 2026 21:07:40 +0000 Message-Id: <20260710210741.02D761F000E9@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 MyBwb3RlbnRpYWwgaXNzdWUocykgdG8gY29uc2lkZXI6CgpOZXcgaXNzdWVzOgotIFtIaWdoXSBS ZW1vdmluZyB0aGUgY2xlYXJhbmNlIG9mIGB1ZHBoeS0+c3RhdHVzYCBpbnRyb2R1Y2VzIHVuYmFs YW5jZWQgY2xvY2sgZGlzYWJsZXMgYW5kIHJlcGVhdGVkIGhhcmR3YXJlIHRlYXJkb3ducyBvbiB0 aGUgYHJrX3VkcGh5X3NldHVwKClgIGVycm9yIHBhdGguCgpQcmUtZXhpc3RpbmcgaXNzdWVzOgot IFtIaWdoXSBNaXNzaW5nIG11dGV4IGFjcXVpc2l0aW9uIGluIGBya191ZHBoeV9kcF9waHlfY29u ZmlndXJlYCBsZWFkcyB0byBkYXRhIHJhY2VzIG9uIHNoYXJlZCBkcml2ZXIgc3RhdGUuCi0gW0hp Z2hdIEluY29tcGxldGUgaGFuZGxpbmcgb2YgbW9kZSB0cmFuc2l0aW9ucyBjYXVzZXMgRFdDMyBT RXJyb3JzIGFuZCBwZXJtYW5lbnRseSBicmVha3MgdGhlIFVTQjMgZGF0YSBzdHJlYW0uCi0tCgot LS0gUGF0Y2ggWzNdOiBbUEFUQ0ggdjEyIDAzLzM2XSBwaHk6IHJvY2tjaGlwOiB1c2JkcDogRG8g bm90IGxvc2UgVVNCMyBQSFkgc3RhdHVzIC0tLQpjb21taXQgZWZlOWJjYjBkNjMyODY0MGU0MzQ2 MWY5ODI4MTZlNDVmNTVmOWEzNgpBdXRob3I6IFNlYmFzdGlhbiBSZWljaGVsIDxzZWJhc3RpYW4u cmVpY2hlbEBjb2xsYWJvcmEuY29tPgoKcGh5OiByb2NrY2hpcDogdXNiZHA6IERvIG5vdCBsb3Nl IFVTQjMgUEhZIHN0YXR1cwoKQnkgZGVmYXVsdCAoaS5lLiB3aXRob3V0IG1hbnVhbGx5IGVuYWJs aW5nIHJ1bnRpbWUgUE0pIERXQzMgcmVxdWVzdHMgdGhlClVTQjMgUEhZIG9uY2UgYW5kIGtlZXBz IGl0IGVuYWJsZWQgYWxsIHRoZSB0aW1lLiBXaGVuIERpc3BsYXlQb3J0IGlzCmJlaW5nIHJlcXVl c3RlZCBsYXRlciBvbiwgYSBtb2RlIGNoYW5nZSBpcyBuZWVkZWQuIFRoaXMgcmUtaW5pdGlhbGl6 ZXMKdGhlIFBIWS4gRHVyaW5nIHJlLWluaXRpYWxpemF0aW9uIHRoZSBzdGF0dXMgdmFyaWFibGUg aGFzIGluY29ycmVjdGx5CmJlZW4gY2xlYXJlZCwgd2hpY2ggbWVhbnMgdGhlIHRyYWNraW5nIGlu Zm9ybWF0aW9uIGZvciBVU0IzIGlzIGxvc3QuCgpUaGlzIGlzIG5vdCBhbiBpbW1lZGlhdGUgcHJv YmxlbSwgc2luY2UgdGhlIERQIHNpZGUga2VlcHMgdGhlIFBIWQplbmFibGVkLiBCdXQgb25jZSBE UCBpcyB0b2dnbGVkIG9mZiwgdGhlIHdob2xlIFBIWSB3aWxsIGJlIGRpc2FibGVkLgpUaGlzIGlz IGEgcHJvYmxlbSwgYmVjYXVzZSB0aGUgVVNCIHNpZGUgc3RpbGwgbmVlZHMgaXQgcG93ZXJlZC4K CkZpeCB0aGluZ3MgYnkgbm90IGNsZWFyaW5nIHRoZSBzdGF0dXMgZmxhZ3MuCgo+IGRpZmYgLS1n aXQgYS9kcml2ZXJzL3BoeS9yb2NrY2hpcC9waHktcm9ja2NoaXAtdXNiZHAuYyBiL2RyaXZlcnMv cGh5L3JvY2tjaGlwL3BoeS1yb2NrY2hpcC11c2JkcC5jCj4gaW5kZXggYTVmZmRmN2E2ZTc2Yi4u MTJkZmRkNDcwYTc4MiAxMDA2NDQKPiAtLS0gYS9kcml2ZXJzL3BoeS9yb2NrY2hpcC9waHktcm9j a2NoaXAtdXNiZHAuYwo+ICsrKyBiL2RyaXZlcnMvcGh5L3JvY2tjaGlwL3BoeS1yb2NrY2hpcC11 c2JkcC5jCj4gQEAgLTEwMDgsNyArMTAwOCw2IEBAIHN0YXRpYyBpbnQgcmtfdWRwaHlfcG93ZXJf b24oc3RydWN0IHJrX3VkcGh5ICp1ZHBoeSwgdTggbW9kZSkKPiAgCQkJcmtfdWRwaHlfdTNfcG9y dF9kaXNhYmxlKHVkcGh5LCBmYWxzZSk7Cj4gIAkJdWRwaHktPm1vZGVfY2hhbmdlID0gZmFsc2U7 Cj4gIAl9IGVsc2UgaWYgKHVkcGh5LT5tb2RlX2NoYW5nZSkgewoKW1NldmVyaXR5OiBIaWdoXQpU aGlzIGlzIGEgcHJlLWV4aXN0aW5nIGlzc3VlLCBidXQgSSBoYXZlIGEgcXVlc3Rpb24gYWJvdXQg aG93IHRoZSBtb2RlCnRyYW5zaXRpb25zIGFyZSBoYW5kbGVkIGhlcmUgaW4gcmtfdWRwaHlfcG93 ZXJfb24oKS4KCldoZW4gVHlwZS1DIG5lZ290aWF0aW9uIGNoYW5nZXMgdGhlIG1vZGUgdG8gVURQ SFlfTU9ERV9EUF9VU0IsIHRoZSBkcml2ZXIKc2tpcHMgY2FsbGluZyBya191ZHBoeV91M19wb3J0 X2Rpc2FibGUodWRwaHksIHRydWUpLiBJdCB0aGVuIGN1dHMgdGhlIFBIWQpjbG9ja3MgdmlhIHJr X3VkcGh5X2Rpc2FibGUoKSB3aGlsZSB0aGUgRFdDMyBjb250cm9sbGVyIG1pZ2h0IHN0aWxsIGJl CmFjdGl2ZS4gQ2FuIHRoaXMgY2F1c2UgU3lzdGVtIEVycm9ycyAoU0Vycm9ycykgZnJvbSB0aGUg RFdDMyBjb250cm9sbGVyPwoKQWRkaXRpb25hbGx5LCBpZiB0aGUgb2xkIG1vZGUgd2FzIFVEUEhZ X01PREVfRFAsIHRoZSBVU0IzIHBvcnQgaXMgZGlzYWJsZWQKYnV0IG5ldmVyIHJlLWVuYWJsZWQg YWZ0ZXIgcmtfdWRwaHlfc2V0dXAoKSBzdWNjZWVkcy4gRG9lcyB0aGlzIGxlYXZlIHRoZQpVU0Iz IGRhdGEgc3RyZWFtIHBlcm1hbmVudGx5IGJyb2tlbiBpbiB0aGUgR1JGIHJlZ2lzdGVycz8KCj4g LQkJdWRwaHktPnN0YXR1cyA9IFVEUEhZX01PREVfTk9ORTsKPiAgCQlpZiAodWRwaHktPm1vZGUg PT0gVURQSFlfTU9ERV9EUCkKPiAgCQkJcmtfdWRwaHlfdTNfcG9ydF9kaXNhYmxlKHVkcGh5LCB0 cnVlKTsKPiAgCj4gIAkJcmtfdWRwaHlfZGlzYWJsZSh1ZHBoeSk7Cj4gIAkJcmV0ID0gcmtfdWRw aHlfc2V0dXAodWRwaHkpOwo+ICAJCWlmIChyZXQpCj4gIAkJCXJldHVybiByZXQ7CgpbU2V2ZXJp dHk6IEhpZ2hdClNpbmNlIHRoaXMgY2xlYXJhbmNlIGlzIHJlbW92ZWQsIHdoYXQgaGFwcGVucyBp ZiBya191ZHBoeV9zZXR1cCgpIGZhaWxzCmltbWVkaWF0ZWx5IGFmdGVyIHRoaXMgYmxvY2s/CgpJ ZiBya191ZHBoeV9zZXR1cCgpIHJldHVybnMgYW4gZXJyb3IsIHRoZSBmdW5jdGlvbiBleGl0cyB3 aXRob3V0IHVwZGF0aW5nCnVkcGh5LT5zdGF0dXMgdG8gcmVmbGVjdCB0aGF0IHRoZSBoYXJkd2Fy ZSB3YXMgYWN0dWFsbHkgZGlzYWJsZWQgYnkKcmtfdWRwaHlfZGlzYWJsZSgpIGp1c3QgYWJvdmUu CgpDb3VsZCB0aGlzIGxlYWQgdG8gdW5iYWxhbmNlZCBjbG9jayBkaXNhYmxlcyBhbmQgcmVwZWF0 ZWQgcmVzZXRzIGxhdGVyIHdoZW4KcGh5X3Bvd2VyX29mZigpIG9yIHBoeV9wb3dlcl9vbigpIGlz IGNhbGxlZCwgc2luY2UgdGhlIGRyaXZlciBzdGlsbCBhc3N1bWVzCnRoZSBQSFkgaXMgYWN0aXZl PwoKWyAuLi4gXQoKW1NldmVyaXR5OiBIaWdoXQpUaGlzIGlzIGEgcHJlLWV4aXN0aW5nIGlzc3Vl LCBidXQgZG9lcyBya191ZHBoeV9kcF9waHlfY29uZmlndXJlKCkgbmVlZCB0bwpob2xkIHVkcGh5 LT5tdXRleCB3aGVuIGFjY2Vzc2luZyBzaGFyZWQgZHJpdmVyIHN0YXRlPwoKTG9va2luZyBhdCBk cml2ZXJzL3BoeS9yb2NrY2hpcC9waHktcm9ja2NoaXAtdXNiZHAuYzoKCnJrX3VkcGh5X2RwX3Bo eV9jb25maWd1cmUoKSB7CglzdHJ1Y3QgcmtfdWRwaHkgKnVkcGh5ID0gcGh5X2dldF9kcnZkYXRh KHBoeSk7CgkuLi4KCWlmIChkcC0+c2V0X3ZvbHRhZ2VzKSB7CgkJZm9yIChpID0gMDsgaSA8IHVk cGh5LT5sYW5lczsgaSsrKSB7CgkJCWxhbmUgPSB1ZHBoeS0+ZHBfbGFuZV9zZWxbaV07Ci4uLgoK VGhpcyBmdW5jdGlvbiByZWFkcyB1ZHBoeS0+ZHBfbGFuZV9zZWwsIHVkcGh5LT5sYW5lcywgYW5k CnVkcGh5LT5sYW5lX211eF9zZWwgd2l0aG91dCBhY3F1aXJpbmcgdGhlIG11dGV4LgoKTWVhbndo aWxlLCBpZiBhIFR5cGUtQyBvcmllbnRhdGlvbiBmbGlwIG9jY3VycywgcmtfdWRwaHlfb3JpZW5f c3dfc2V0KCkKYWNxdWlyZXMgdGhlIG11dGV4IGFuZCBtdXRhdGVzIHRoaXMgZXhhY3Qgc3RhdGU6 Cgpya191ZHBoeV9vcmllbl9zd19zZXQoKSB7CgkuLi4KCW11dGV4X2xvY2soJnVkcGh5LT5tdXRl eCk7CgkuLi4KCXVkcGh5LT5mbGlwID0gb3JpZW4gPT0gVFlQRUNfT1JJRU5UQVRJT05fUkVWRVJT RTsKCXJrX3VkcGh5X3NldF90eXBlY19kZWZhdWx0X21hcHBpbmcodWRwaHkpOwouLi4KCkNhbiB0 aGlzIGRhdGEgcmFjZSBjYXVzZSB2b2x0YWdlcyB0byBiZSBwcm9ncmFtbWVkIHRvIHRoZSB3cm9u ZyBQSFkgbGFuZXMsCmxlYWRpbmcgdG8gRFAgbGluayB0cmFpbmluZyBmYWlsdXJlcyBpZiBhIGNh YmxlIGlzIGZsaXBwZWQgZHVyaW5nIGFjdGl2ZQpEaXNwbGF5UG9ydCB1c2U/CgotLSAKU2FzaGlr byBBSSByZXZpZXcgwrcgaHR0cHM6Ly9zYXNoaWtvLmRldi8jL3BhdGNoc2V0LzIwMjYwNzEwLXJv Y2tjaGlwLXVzYmRwLWNsZWFudXAtdjEyLTAtOGI0MWE5YTliZWYwQGNvbGxhYm9yYS5jb20/cGFy dD0zCgotLSAKbGludXgtcGh5IG1haWxpbmcgbGlzdApsaW51eC1waHlAbGlzdHMuaW5mcmFkZWFk Lm9yZwpodHRwczovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1w aHkK