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 01BED3E51EF for ; Tue, 14 Jul 2026 19:49:10 +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=1784058552; cv=none; b=Z/MWkiodzI4mvbYFUPqnRYsBil3SkZG5wkmvYuZpD+dnIX37bPWqQ7XR487QO7gIey/ltCvNAAlom4ehAP4n0jO954i0RNaUt/6uNSXRL7DSGK1D1kR9Wf6VYNoz5rpQGqfkETxtrzNVDdIcb0FdZ5AFDMjiIZ6tNO+ZDNrut+g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784058552; c=relaxed/simple; bh=u+1+qEBEdXOFnSmSTL5zZPTbf+fnXxujVz9of+aWqa4=; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date: Message-Id; b=Xze9KdLmylcBP216frwVcxNBGNujWRVPwCmaNdew3KynzFTwIGmWfzxVS6V6ynoikgsAxUlg3EogDGW+9Hc3aoVO4P+EflEUkWrCZcMVRZSS4wfK4C7snwCID3TIw6/B4Vdpjhfm34JEEVDoIkt8wDzfx0COgsZwNzVlzXAnsE0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=fXyZ0i26; 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="fXyZ0i26" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 13B941F000E9; Tue, 14 Jul 2026 19:49:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1784058550; bh=5Q/styvhIXpLetkJ2vEn3tKPaL9M825eB16Rpj8C8uM=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=fXyZ0i26y42jJXQ2AFObNEFRa17feBUOS/MM+Vptxn64a8bUl5oW3D5c+d1dG7fE4 cdQwDAgHqa6Db/9T23w3Xopb1OLfiFo72MLU8eWAcO6u35Q1l06rNM5ECLsB9oT+vQ l4HvWxARtw9Zimc/qG6o0bPqTzh7RoM+FviDa+ewxN1ULtfoARocHQmeUsTgp18BKb qrm694N+Vod/dkhJGZAVg6+RciytUgCzvFOz4bU67EWMciS2DDp5H9/jPs8o5PCoiH 6hLAoo2RN5Hc2vWL/TRUxvOhixf2xC3NbkxzrnQFc/JMwhAJeXxhNt45AEQ5TJIqgi Ctbh2IRG/ypXA== From: sashiko-bot@kernel.org Subject: Re: [PATCH v13 03/35] phy: rockchip: usbdp: Do not lose USB3 PHY status Reply-To: sashiko-reviews@lists.linux.dev To: "Sebastian Reichel" Cc: olteanv@gmail.com, robh@kernel.org, conor+dt@kernel.org, devicetree@vger.kernel.org, vkoul@kernel.org, neil.armstrong@linaro.org, linux-phy@lists.infradead.org In-Reply-To: <20260714-rockchip-usbdp-cleanup-v13-3-6cb3e769d4c5@collabora.com> References: <20260714-rockchip-usbdp-cleanup-v13-0-6cb3e769d4c5@collabora.com> <20260714-rockchip-usbdp-cleanup-v13-3-6cb3e769d4c5@collabora.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 14 Jul 2026 19:49:09 +0000 Message-Id: <20260714194910.13B941F000E9@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 5 potential issue(= s) to consider: New issues: - [High] State desynchronization on PHY setup failure causes double clock d= isable. - [High] USB status bit permanently sticks when transitioning to DP-only mo= de, causing a permanent hardware power leak. Pre-existing issues: - [High] USB3 port remains permanently disabled after Type-C transitions fr= om DP-only to DP+USB. - [High] Clock resource leak on probe failure and module unload if the boot= loader left the PHY enabled. - [High] Data race in `rk_udphy_dp_phy_configure` leading to corrupted DP l= ane configuration. -- --- Patch [3]: [PATCH v13 03/35] phy: rockchip: usbdp: Do not lose USB3 PHY= status --- commit d46c4c27785a2f2be7f57da59562db8997835bf3 Author: Sebastian Reichel phy: rockchip: usbdp: Do not lose USB3 PHY status This patch modifies the Rockchip USB/DP combo PHY driver to prevent the sta= tus variable from being cleared during a DP mode change. This ensures that the tracking information for USB3 is not lost when re-initializing the PHY. > 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) { > - udphy->status =3D UDPHY_MODE_NONE; [Severity: High] If rk_udphy_setup() fails in the subsequent step (e.g., due to a PLL lock timeout), could this cause a state desynchronization? By no longer clearing the status here, the previous active flags remain if = the setup fails: drivers/phy/rockchip/phy-rockchip-usbdp.c:rk_udphy_power_on() { ... } else if (udphy->mode_change) { if (udphy->mode =3D=3D UDPHY_MODE_DP) rk_udphy_u3_port_disable(udphy, true); rk_udphy_disable(udphy); ret =3D rk_udphy_setup(udphy); if (ret) return ret; ... } When the consumer unwinds the failure and calls phy_power_off(), the driver will see the non-zero status, clear the bit, and invoke rk_udphy_disable() a second time on already disabled clocks. Will this cause the clock enable refcount to underflow and generate a kernel warning? [Severity: High] Additionally, does removing this clearance cause a permanent hardware power leak when transitioning to a DP-only mode? If the Type-C port negotiates a DP-only mode, udphy->mode changes to UDPHY_MODE_DP, but the UDPHY_MODE_USB bit now persists in udphy->status from prior initialization. Later, if the USB core suspends or unbinds, rk_udphy_usb3_phy_exit() is cal= led: drivers/phy/rockchip/phy-rockchip-usbdp.c:rk_udphy_usb3_phy_exit() { ... /* DP only or high-speed */ if (!(udphy->mode & UDPHY_MODE_USB) || udphy->hs) goto unlock; rk_udphy_power_off(udphy, UDPHY_MODE_USB); ... } Because udphy->mode is UDPHY_MODE_DP, it skips the call to rk_udphy_power_off(), meaning the UDPHY_MODE_USB bit is never cleared. When the DP consumer eventually powers off, rk_udphy_disable() is skipped because status remains non-zero, leaving the clocks permanently enabled. > if (udphy->mode =3D=3D UDPHY_MODE_DP) > rk_udphy_u3_port_disable(udphy, true); [Severity: High] This is a pre-existing issue, but does this block fail to explicitly re-ena= ble the USB3 port when transitioning to a mode that requires it? When transitioning from a DP-only mode to a DP+USB combo mode, udphy->mode changes to UDPHY_MODE_DP_USB and udphy->mode_change is set to true. During rk_udphy_power_on(), the code previously disabled the U3 port when entering DP-only mode. However, when transitioning back to DP+USB, the code skips the initial UDPHY_MODE_NONE block and enters the else if (udphy->mode_change) block, which entirely lacks a call to explicit= ly re-enable the port via rk_udphy_u3_port_disable(udphy, false). Will the GRF register retain the disabled state indefinitely, silently breaking USB3 functionality? [Severity: High] This isn't a bug introduced by this patch, but does the driver leak clock resources if the bootloader left the PHY enabled and probe fails? In rk_udphy_get_initial_status(), if it detects the PHY was already enabled by the bootloader, it intentionally skips disabling the clocks: drivers/phy/rockchip/phy-rockchip-usbdp.c:rk_udphy_get_initial_status() { ... regmap_read(udphy->pma_regmap, CMN_LANE_MUX_AND_EN_OFFSET, &value); if (FIELD_GET(CMN_DP_LANE_MUX_ALL, value) && FIELD_GET(CMN_DP_LANE_EN_ALL, value)) udphy->status =3D UDPHY_MODE_DP; else rk_udphy_disable(udphy); ... } Since there is no devm cleanup action registered for these manually enabled clocks, if a subsequent probe step like devm_phy_create() fails, probe returns an error without disabling them. Furthermore, since the platform driver lacks a .remove callback, will the module leak these clocks if it is cleanly unloaded? [Severity: High] This is a pre-existing issue, but is there a data race in rk_udphy_dp_phy_configure() that could lead to corrupted DP lane configurat= ion? drivers/phy/rockchip/phy-rockchip-usbdp.c:rk_udphy_dp_phy_configure() { ... if (dp->set_voltages) { for (i =3D 0; i < udphy->lanes; i++) { lane =3D udphy->dp_lane_sel[i]; ... } The udphy->dp_lane_sel and udphy->lane_mux_sel arrays are read without holding udphy->mutex. Concurrently, if a Type-C orientation flip occurs, the TCPM worker thread calls rk_udphy_orien_sw_set(), which mutates these exact arrays under udphy->mutex. If the DP driver performs link training concurrently with an orientation fl= ip, could it read partially updated lane arrays and write invalid voltage swing configurations to incorrect lane registers on the PHY? --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260714-rockchip-u= sbdp-cleanup-v13-0-6cb3e769d4c5@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 2333BC44507 for ; Tue, 14 Jul 2026 19:49:13 +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=RXKvjw2kMXrWE2ab8CzMN+2GHxfCbXo9SekWq40aftw=; b=PctCG3Tgy/lgqj NYu8tTIHmL3sYe+8Rb1ifSe9rAM6Wz/fMJn9a+SojpPXpk0SqwYwFvKiL3UBEM3HfiPWtJglQndkj nWR8LHq3mxMuTzE6una7nHRwbUk4nI43ReewxHVutOzQaNeRimhqPOg0DZfTsbzd0reuVCJcHUHE4 4ALvCXCOB4VP5R7qccNuFKwc+i3+sj9CYSkDnEt5EdgLMCMf17G0xoSB6bdAAOXxKBbywTeHkYIe+ 1sv2npfcTTHZeZDGB/FuLGv/Dghpd9BAGUvqDzltUURGhxDV25JPZXVT4bzD8a5L2yRqnXQ4fZ2oD y7Q4EIJLLRYudtpfi7Ag==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wjj7w-0000000DA7G-3VTQ; Tue, 14 Jul 2026 19:49:12 +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 1wjj7v-0000000DA6r-3Fr2 for linux-phy@lists.infradead.org; Tue, 14 Jul 2026 19:49:11 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id AB106403CF; Tue, 14 Jul 2026 19:49:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 13B941F000E9; Tue, 14 Jul 2026 19:49:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1784058550; bh=5Q/styvhIXpLetkJ2vEn3tKPaL9M825eB16Rpj8C8uM=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=fXyZ0i26y42jJXQ2AFObNEFRa17feBUOS/MM+Vptxn64a8bUl5oW3D5c+d1dG7fE4 cdQwDAgHqa6Db/9T23w3Xopb1OLfiFo72MLU8eWAcO6u35Q1l06rNM5ECLsB9oT+vQ l4HvWxARtw9Zimc/qG6o0bPqTzh7RoM+FviDa+ewxN1ULtfoARocHQmeUsTgp18BKb qrm694N+Vod/dkhJGZAVg6+RciytUgCzvFOz4bU67EWMciS2DDp5H9/jPs8o5PCoiH 6hLAoo2RN5Hc2vWL/TRUxvOhixf2xC3NbkxzrnQFc/JMwhAJeXxhNt45AEQ5TJIqgi Ctbh2IRG/ypXA== From: sashiko-bot@kernel.org Subject: Re: [PATCH v13 03/35] phy: rockchip: usbdp: Do not lose USB3 PHY status To: "Sebastian Reichel" Cc: olteanv@gmail.com, robh@kernel.org, conor+dt@kernel.org, devicetree@vger.kernel.org, vkoul@kernel.org, neil.armstrong@linaro.org, linux-phy@lists.infradead.org In-Reply-To: <20260714-rockchip-usbdp-cleanup-v13-3-6cb3e769d4c5@collabora.com> References: <20260714-rockchip-usbdp-cleanup-v13-0-6cb3e769d4c5@collabora.com> <20260714-rockchip-usbdp-cleanup-v13-3-6cb3e769d4c5@collabora.com> Date: Tue, 14 Jul 2026 19:49:09 +0000 Message-Id: <20260714194910.13B941F000E9@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 NSBwb3RlbnRpYWwgaXNzdWUocykgdG8gY29uc2lkZXI6CgpOZXcgaXNzdWVzOgotIFtIaWdoXSBT dGF0ZSBkZXN5bmNocm9uaXphdGlvbiBvbiBQSFkgc2V0dXAgZmFpbHVyZSBjYXVzZXMgZG91Ymxl IGNsb2NrIGRpc2FibGUuCi0gW0hpZ2hdIFVTQiBzdGF0dXMgYml0IHBlcm1hbmVudGx5IHN0aWNr cyB3aGVuIHRyYW5zaXRpb25pbmcgdG8gRFAtb25seSBtb2RlLCBjYXVzaW5nIGEgcGVybWFuZW50 IGhhcmR3YXJlIHBvd2VyIGxlYWsuCgpQcmUtZXhpc3RpbmcgaXNzdWVzOgotIFtIaWdoXSBVU0Iz IHBvcnQgcmVtYWlucyBwZXJtYW5lbnRseSBkaXNhYmxlZCBhZnRlciBUeXBlLUMgdHJhbnNpdGlv bnMgZnJvbSBEUC1vbmx5IHRvIERQK1VTQi4KLSBbSGlnaF0gQ2xvY2sgcmVzb3VyY2UgbGVhayBv biBwcm9iZSBmYWlsdXJlIGFuZCBtb2R1bGUgdW5sb2FkIGlmIHRoZSBib290bG9hZGVyIGxlZnQg dGhlIFBIWSBlbmFibGVkLgotIFtIaWdoXSBEYXRhIHJhY2UgaW4gYHJrX3VkcGh5X2RwX3BoeV9j b25maWd1cmVgIGxlYWRpbmcgdG8gY29ycnVwdGVkIERQIGxhbmUgY29uZmlndXJhdGlvbi4KLS0K Ci0tLSBQYXRjaCBbM106IFtQQVRDSCB2MTMgMDMvMzVdIHBoeTogcm9ja2NoaXA6IHVzYmRwOiBE byBub3QgbG9zZSBVU0IzIFBIWSBzdGF0dXMgLS0tCmNvbW1pdCBkNDZjNGMyNzc4NWEyZjJiZTdm NTdkYTU5NTYyZGI4OTk3ODM1YmYzCkF1dGhvcjogU2ViYXN0aWFuIFJlaWNoZWwgPHNlYmFzdGlh bi5yZWljaGVsQGNvbGxhYm9yYS5jb20+CgpwaHk6IHJvY2tjaGlwOiB1c2JkcDogRG8gbm90IGxv c2UgVVNCMyBQSFkgc3RhdHVzCgpUaGlzIHBhdGNoIG1vZGlmaWVzIHRoZSBSb2NrY2hpcCBVU0Iv RFAgY29tYm8gUEhZIGRyaXZlciB0byBwcmV2ZW50IHRoZSBzdGF0dXMKdmFyaWFibGUgZnJvbSBi ZWluZyBjbGVhcmVkIGR1cmluZyBhIERQIG1vZGUgY2hhbmdlLiBUaGlzIGVuc3VyZXMgdGhhdCB0 aGUKdHJhY2tpbmcgaW5mb3JtYXRpb24gZm9yIFVTQjMgaXMgbm90IGxvc3Qgd2hlbiByZS1pbml0 aWFsaXppbmcgdGhlIFBIWS4KCj4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvcGh5L3JvY2tjaGlwL3Bo eS1yb2NrY2hpcC11c2JkcC5jIGIvZHJpdmVycy9waHkvcm9ja2NoaXAvcGh5LXJvY2tjaGlwLXVz YmRwLmMKPiBpbmRleCBhNWZmZGY3YTZlNzZiLi4xMmRmZGQ0NzBhNzgyIDEwMDY0NAo+IC0tLSBh L2RyaXZlcnMvcGh5L3JvY2tjaGlwL3BoeS1yb2NrY2hpcC11c2JkcC5jCj4gKysrIGIvZHJpdmVy cy9waHkvcm9ja2NoaXAvcGh5LXJvY2tjaGlwLXVzYmRwLmMKPiBAQCAtMTAwOCw3ICsxMDA4LDYg QEAgc3RhdGljIGludCBya191ZHBoeV9wb3dlcl9vbihzdHJ1Y3QgcmtfdWRwaHkgKnVkcGh5LCB1 OCBtb2RlKQo+ICAJCQlya191ZHBoeV91M19wb3J0X2Rpc2FibGUodWRwaHksIGZhbHNlKTsKPiAg CQl1ZHBoeS0+bW9kZV9jaGFuZ2UgPSBmYWxzZTsKPiAgCX0gZWxzZSBpZiAodWRwaHktPm1vZGVf Y2hhbmdlKSB7Cj4gLQkJdWRwaHktPnN0YXR1cyA9IFVEUEhZX01PREVfTk9ORTsKCltTZXZlcml0 eTogSGlnaF0KSWYgcmtfdWRwaHlfc2V0dXAoKSBmYWlscyBpbiB0aGUgc3Vic2VxdWVudCBzdGVw IChlLmcuLCBkdWUgdG8gYSBQTEwgbG9jawp0aW1lb3V0KSwgY291bGQgdGhpcyBjYXVzZSBhIHN0 YXRlIGRlc3luY2hyb25pemF0aW9uPwoKQnkgbm8gbG9uZ2VyIGNsZWFyaW5nIHRoZSBzdGF0dXMg aGVyZSwgdGhlIHByZXZpb3VzIGFjdGl2ZSBmbGFncyByZW1haW4gaWYgdGhlCnNldHVwIGZhaWxz OgoKZHJpdmVycy9waHkvcm9ja2NoaXAvcGh5LXJvY2tjaGlwLXVzYmRwLmM6cmtfdWRwaHlfcG93 ZXJfb24oKSB7CiAgICAuLi4KCX0gZWxzZSBpZiAodWRwaHktPm1vZGVfY2hhbmdlKSB7CgkJaWYg KHVkcGh5LT5tb2RlID09IFVEUEhZX01PREVfRFApCgkJCXJrX3VkcGh5X3UzX3BvcnRfZGlzYWJs ZSh1ZHBoeSwgdHJ1ZSk7CgoJCXJrX3VkcGh5X2Rpc2FibGUodWRwaHkpOwoJCXJldCA9IHJrX3Vk cGh5X3NldHVwKHVkcGh5KTsKCQlpZiAocmV0KQoJCQlyZXR1cm4gcmV0OwogICAgLi4uCn0KCldo ZW4gdGhlIGNvbnN1bWVyIHVud2luZHMgdGhlIGZhaWx1cmUgYW5kIGNhbGxzIHBoeV9wb3dlcl9v ZmYoKSwgdGhlIGRyaXZlcgp3aWxsIHNlZSB0aGUgbm9uLXplcm8gc3RhdHVzLCBjbGVhciB0aGUg Yml0LCBhbmQgaW52b2tlIHJrX3VkcGh5X2Rpc2FibGUoKSBhCnNlY29uZCB0aW1lIG9uIGFscmVh ZHkgZGlzYWJsZWQgY2xvY2tzLiBXaWxsIHRoaXMgY2F1c2UgdGhlIGNsb2NrIGVuYWJsZQpyZWZj b3VudCB0byB1bmRlcmZsb3cgYW5kIGdlbmVyYXRlIGEga2VybmVsIHdhcm5pbmc/CgpbU2V2ZXJp dHk6IEhpZ2hdCkFkZGl0aW9uYWxseSwgZG9lcyByZW1vdmluZyB0aGlzIGNsZWFyYW5jZSBjYXVz ZSBhIHBlcm1hbmVudCBoYXJkd2FyZSBwb3dlcgpsZWFrIHdoZW4gdHJhbnNpdGlvbmluZyB0byBh IERQLW9ubHkgbW9kZT8KCklmIHRoZSBUeXBlLUMgcG9ydCBuZWdvdGlhdGVzIGEgRFAtb25seSBt b2RlLCB1ZHBoeS0+bW9kZSBjaGFuZ2VzIHRvClVEUEhZX01PREVfRFAsIGJ1dCB0aGUgVURQSFlf TU9ERV9VU0IgYml0IG5vdyBwZXJzaXN0cyBpbiB1ZHBoeS0+c3RhdHVzIGZyb20KcHJpb3IgaW5p dGlhbGl6YXRpb24uCgpMYXRlciwgaWYgdGhlIFVTQiBjb3JlIHN1c3BlbmRzIG9yIHVuYmluZHMs IHJrX3VkcGh5X3VzYjNfcGh5X2V4aXQoKSBpcyBjYWxsZWQ6Cgpkcml2ZXJzL3BoeS9yb2NrY2hp cC9waHktcm9ja2NoaXAtdXNiZHAuYzpya191ZHBoeV91c2IzX3BoeV9leGl0KCkgewogICAgLi4u CgkvKiBEUCBvbmx5IG9yIGhpZ2gtc3BlZWQgKi8KCWlmICghKHVkcGh5LT5tb2RlICYgVURQSFlf TU9ERV9VU0IpIHx8IHVkcGh5LT5ocykKCQlnb3RvIHVubG9jazsKCglya191ZHBoeV9wb3dlcl9v ZmYodWRwaHksIFVEUEhZX01PREVfVVNCKTsKICAgIC4uLgp9CgpCZWNhdXNlIHVkcGh5LT5tb2Rl IGlzIFVEUEhZX01PREVfRFAsIGl0IHNraXBzIHRoZSBjYWxsIHRvCnJrX3VkcGh5X3Bvd2VyX29m ZigpLCBtZWFuaW5nIHRoZSBVRFBIWV9NT0RFX1VTQiBiaXQgaXMgbmV2ZXIgY2xlYXJlZC4KV2hl biB0aGUgRFAgY29uc3VtZXIgZXZlbnR1YWxseSBwb3dlcnMgb2ZmLCBya191ZHBoeV9kaXNhYmxl KCkgaXMgc2tpcHBlZApiZWNhdXNlIHN0YXR1cyByZW1haW5zIG5vbi16ZXJvLCBsZWF2aW5nIHRo ZSBjbG9ja3MgcGVybWFuZW50bHkgZW5hYmxlZC4KCj4gIAkJaWYgKHVkcGh5LT5tb2RlID09IFVE UEhZX01PREVfRFApCj4gIAkJCXJrX3VkcGh5X3UzX3BvcnRfZGlzYWJsZSh1ZHBoeSwgdHJ1ZSk7 CgpbU2V2ZXJpdHk6IEhpZ2hdClRoaXMgaXMgYSBwcmUtZXhpc3RpbmcgaXNzdWUsIGJ1dCBkb2Vz IHRoaXMgYmxvY2sgZmFpbCB0byBleHBsaWNpdGx5IHJlLWVuYWJsZQp0aGUgVVNCMyBwb3J0IHdo ZW4gdHJhbnNpdGlvbmluZyB0byBhIG1vZGUgdGhhdCByZXF1aXJlcyBpdD8KCldoZW4gdHJhbnNp dGlvbmluZyBmcm9tIGEgRFAtb25seSBtb2RlIHRvIGEgRFArVVNCIGNvbWJvIG1vZGUsIHVkcGh5 LT5tb2RlCmNoYW5nZXMgdG8gVURQSFlfTU9ERV9EUF9VU0IgYW5kIHVkcGh5LT5tb2RlX2NoYW5n ZSBpcyBzZXQgdG8gdHJ1ZS4KCkR1cmluZyBya191ZHBoeV9wb3dlcl9vbigpLCB0aGUgY29kZSBw cmV2aW91c2x5IGRpc2FibGVkIHRoZSBVMyBwb3J0IHdoZW4KZW50ZXJpbmcgRFAtb25seSBtb2Rl LiBIb3dldmVyLCB3aGVuIHRyYW5zaXRpb25pbmcgYmFjayB0byBEUCtVU0IsIHRoZSBjb2RlCnNr aXBzIHRoZSBpbml0aWFsIFVEUEhZX01PREVfTk9ORSBibG9jayBhbmQgZW50ZXJzIHRoZQplbHNl IGlmICh1ZHBoeS0+bW9kZV9jaGFuZ2UpIGJsb2NrLCB3aGljaCBlbnRpcmVseSBsYWNrcyBhIGNh bGwgdG8gZXhwbGljaXRseQpyZS1lbmFibGUgdGhlIHBvcnQgdmlhIHJrX3VkcGh5X3UzX3BvcnRf ZGlzYWJsZSh1ZHBoeSwgZmFsc2UpLgoKV2lsbCB0aGUgR1JGIHJlZ2lzdGVyIHJldGFpbiB0aGUg ZGlzYWJsZWQgc3RhdGUgaW5kZWZpbml0ZWx5LCBzaWxlbnRseQpicmVha2luZyBVU0IzIGZ1bmN0 aW9uYWxpdHk/CgpbU2V2ZXJpdHk6IEhpZ2hdClRoaXMgaXNuJ3QgYSBidWcgaW50cm9kdWNlZCBi eSB0aGlzIHBhdGNoLCBidXQgZG9lcyB0aGUgZHJpdmVyIGxlYWsgY2xvY2sKcmVzb3VyY2VzIGlm IHRoZSBib290bG9hZGVyIGxlZnQgdGhlIFBIWSBlbmFibGVkIGFuZCBwcm9iZSBmYWlscz8KCklu IHJrX3VkcGh5X2dldF9pbml0aWFsX3N0YXR1cygpLCBpZiBpdCBkZXRlY3RzIHRoZSBQSFkgd2Fz IGFscmVhZHkgZW5hYmxlZApieSB0aGUgYm9vdGxvYWRlciwgaXQgaW50ZW50aW9uYWxseSBza2lw cyBkaXNhYmxpbmcgdGhlIGNsb2NrczoKCmRyaXZlcnMvcGh5L3JvY2tjaGlwL3BoeS1yb2NrY2hp cC11c2JkcC5jOnJrX3VkcGh5X2dldF9pbml0aWFsX3N0YXR1cygpIHsKICAgIC4uLgoJcmVnbWFw X3JlYWQodWRwaHktPnBtYV9yZWdtYXAsIENNTl9MQU5FX01VWF9BTkRfRU5fT0ZGU0VULCAmdmFs dWUpOwoJaWYgKEZJRUxEX0dFVChDTU5fRFBfTEFORV9NVVhfQUxMLCB2YWx1ZSkgJiYKCSAgICBG SUVMRF9HRVQoQ01OX0RQX0xBTkVfRU5fQUxMLCB2YWx1ZSkpCgkJdWRwaHktPnN0YXR1cyA9IFVE UEhZX01PREVfRFA7CgllbHNlCgkJcmtfdWRwaHlfZGlzYWJsZSh1ZHBoeSk7CiAgICAuLi4KfQoK U2luY2UgdGhlcmUgaXMgbm8gZGV2bSBjbGVhbnVwIGFjdGlvbiByZWdpc3RlcmVkIGZvciB0aGVz ZSBtYW51YWxseSBlbmFibGVkCmNsb2NrcywgaWYgYSBzdWJzZXF1ZW50IHByb2JlIHN0ZXAgbGlr ZSBkZXZtX3BoeV9jcmVhdGUoKSBmYWlscywgcHJvYmUKcmV0dXJucyBhbiBlcnJvciB3aXRob3V0 IGRpc2FibGluZyB0aGVtLiBGdXJ0aGVybW9yZSwgc2luY2UgdGhlIHBsYXRmb3JtCmRyaXZlciBs YWNrcyBhIC5yZW1vdmUgY2FsbGJhY2ssIHdpbGwgdGhlIG1vZHVsZSBsZWFrIHRoZXNlIGNsb2Nr cyBpZiBpdCBpcwpjbGVhbmx5IHVubG9hZGVkPwoKW1NldmVyaXR5OiBIaWdoXQpUaGlzIGlzIGEg cHJlLWV4aXN0aW5nIGlzc3VlLCBidXQgaXMgdGhlcmUgYSBkYXRhIHJhY2UgaW4KcmtfdWRwaHlf ZHBfcGh5X2NvbmZpZ3VyZSgpIHRoYXQgY291bGQgbGVhZCB0byBjb3JydXB0ZWQgRFAgbGFuZSBj b25maWd1cmF0aW9uPwoKZHJpdmVycy9waHkvcm9ja2NoaXAvcGh5LXJvY2tjaGlwLXVzYmRwLmM6 cmtfdWRwaHlfZHBfcGh5X2NvbmZpZ3VyZSgpIHsKICAgIC4uLgoJaWYgKGRwLT5zZXRfdm9sdGFn ZXMpIHsKCQlmb3IgKGkgPSAwOyBpIDwgdWRwaHktPmxhbmVzOyBpKyspIHsKCQkJbGFuZSA9IHVk cGh5LT5kcF9sYW5lX3NlbFtpXTsKICAgIC4uLgp9CgpUaGUgdWRwaHktPmRwX2xhbmVfc2VsIGFu ZCB1ZHBoeS0+bGFuZV9tdXhfc2VsIGFycmF5cyBhcmUgcmVhZCB3aXRob3V0CmhvbGRpbmcgdWRw aHktPm11dGV4LgoKQ29uY3VycmVudGx5LCBpZiBhIFR5cGUtQyBvcmllbnRhdGlvbiBmbGlwIG9j Y3VycywgdGhlIFRDUE0gd29ya2VyIHRocmVhZApjYWxscyBya191ZHBoeV9vcmllbl9zd19zZXQo KSwgd2hpY2ggbXV0YXRlcyB0aGVzZSBleGFjdCBhcnJheXMgdW5kZXIKdWRwaHktPm11dGV4LgoK SWYgdGhlIERQIGRyaXZlciBwZXJmb3JtcyBsaW5rIHRyYWluaW5nIGNvbmN1cnJlbnRseSB3aXRo IGFuIG9yaWVudGF0aW9uIGZsaXAsCmNvdWxkIGl0IHJlYWQgcGFydGlhbGx5IHVwZGF0ZWQgbGFu ZSBhcnJheXMgYW5kIHdyaXRlIGludmFsaWQgdm9sdGFnZSBzd2luZwpjb25maWd1cmF0aW9ucyB0 byBpbmNvcnJlY3QgbGFuZSByZWdpc3RlcnMgb24gdGhlIFBIWT8KCi0tIApTYXNoaWtvIEFJIHJl dmlldyDCtyBodHRwczovL3Nhc2hpa28uZGV2LyMvcGF0Y2hzZXQvMjAyNjA3MTQtcm9ja2NoaXAt dXNiZHAtY2xlYW51cC12MTMtMC02Y2IzZTc2OWQ0YzVAY29sbGFib3JhLmNvbT9wYXJ0PTMKCi0t IApsaW51eC1waHkgbWFpbGluZyBsaXN0CmxpbnV4LXBoeUBsaXN0cy5pbmZyYWRlYWQub3JnCmh0 dHBzOi8vbGlzdHMuaW5mcmFkZWFkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LXBoeQo=