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 14F3C3B3BE7 for ; Fri, 31 Jul 2026 09:22:14 +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=1785489735; cv=none; b=Oj6RB3+ArF1PLWxD17iCe5e2U7y89Jyqos0QjEfz8pHtdSglL1sJXcna+fF6WpIC4w3XRH+8r8VATkjXTvwGXr4rQ9bwcBqKN07hhLnvzFUxxLawpDRcPfqDETJdfdTdWDvXiN/Pvd8nIfR0i+XW+jbkcWVlIpMIWClmzXhOGmw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785489735; c=relaxed/simple; bh=oy5ANf398pgn23U+rslxwaaSgXWo31OwBx7fL/IxUwQ=; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date: Message-Id; b=Jy1ly/jrQfIfZSTOkzB4pEdSw/ESYJIXIH/h2XA0hYNWfkUUwZ0F6RGQ/7qdpRMkLJriznuZUgkyGhK/7pKKhqgWnxoxK+PBl9ea2/VPI3LD32QS22B/HfrXm06vcSewFgPtoC/PQ6P0mtJz6nobQSZsSzJyLs6yFryoov5FbTA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=PQ9wmZYZ; 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="PQ9wmZYZ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9D5E71F000E9; Fri, 31 Jul 2026 09:22:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785489734; bh=buFpopr7n/hOL7T9hO29/5vNknhfH/3Ab58MQyljmVU=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=PQ9wmZYZ0e3z53BIcWXL6Hv1m51zsk/tZWysVjrp8Tu1a60lwX54+WTeUgdEFvy3E fHRv34OF0i2QBa5Lg/Hcza6gFkfcj2kggTCu1ozWnEwrtHaj9EE0+Dwphq2JFCni66 nM+Cie/vC/eQfJ77fmbcMkZHlPRY2jA0o5KONtU2mpHZt5osmAFZBCbaw/uS/yhHAP 5OhZgL11gUNdirAtWRKC/fdqrmXuolo25i5d7TzlEAWJqxL0tPi3r0BX21QTE4QBHh ZiykYOivKEcuGP3NqEzsKuGJNN4kPPUYZrq64Fppw1gtlQ4t4VSPnQ+FQKA4T73dfR Lf3yUc5QmDYIw== From: sashiko-bot@kernel.org Subject: Re: [PATCH v3 2/4] spi: amlogic: spisg: Fix transfer size limit and timeout handling Reply-To: sashiko-reviews@lists.linux.dev To: "Xianwei Zhao" Cc: neil.armstrong@linaro.org, devicetree@vger.kernel.org, linux-amlogic@lists.infradead.org, robh@kernel.org, conor+dt@kernel.org In-Reply-To: <20260731-a9-spisg-v3-2-a15da3f70029@amlogic.com> References: <20260731-a9-spisg-v3-0-a15da3f70029@amlogic.com> <20260731-a9-spisg-v3-2-a15da3f70029@amlogic.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Fri, 31 Jul 2026 09:22:13 +0000 Message-Id: <20260731092213.9D5E71F000E9@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] The newly added timeout abort path stops the controller but fails = to synchronize or disable pending interrupts, causing a race condition wher= e a late interrupt can falsely complete a subsequent transfer. Pre-existing issues: - [High] Transfers exceeding SPISG_BLOCK_MAX blocks are silently truncated = by the driver because it caps the block count but fails to implement the ma= x_transfer_size controller callback. - [High] The driver incorrectly mixes `devm_clk_get_enabled()` with manual = `clk_disable_unprepare()` calls, leading to unbalanced clock reference coun= ting. -- --- Patch [2]: [PATCH v3 2/4] spi: amlogic: spisg: Fix transfer size limit = and timeout handling --- commit f3597777f9b3ab326fe08698fcd9389c455e53d4 Author: Xianwei Zhao spi: amlogic: spisg: Fix transfer size limit and timeout handling The commit reduces SPISG_BLOCK_MAX to avoid zero-length transfers and fixes a 64-bit delay calculation. It also clears the descriptor list register on a transfer timeout to stop the controller. > diff --git a/drivers/spi/spi-amlogic-spisg.c b/drivers/spi/spi-amlogic-sp= isg.c > --- a/drivers/spi/spi-amlogic-spisg.c > +++ b/drivers/spi/spi-amlogic-spisg.c > @@ -95,7 +95,7 @@ > =20 > #define SPISG_MAX_REG 0x40 > =20 > -#define SPISG_BLOCK_MAX 0x100000 > +#define SPISG_BLOCK_MAX 0xFFFFF [Severity: High] This isn't a bug introduced by this patch, but does the driver silently truncate large transfers? In aml_spisg_probe(), the driver sets ctlr->max_dma_len =3D SPISG_BLOCK_MAX, but it does not implement the max_transfer_size controller callback. When a transfer is larger than SPISG_BLOCK_MAX, aml_spisg_setup_transfer() silently caps it: blocks =3D min_t(int, blocks, SPISG_BLOCK_MAX); Since the SPI core isn't aware of the maximum transfer size limit, it could submit oversized transfers that get silently truncated. This could leave DMA buffers partially uninitialized on RX. Should we implement the ctlr->max_transfer_size callback to prevent this? [ ... ] > @@ -565,10 +565,13 @@ static int aml_spisg_transfer_one_message(struct sp= i_controller *ctlr, > aml_spisg_pending(spisg, descs_paddr, false, true); > if (wait_for_completion_timeout(&spisg->completion, > spi_controller_is_target(spisg->controller) ? > - MAX_SCHEDULE_TIMEOUT : msecs_to_jiffies(ms))) > + MAX_SCHEDULE_TIMEOUT : msecs_to_jiffies(ms))) { > ret =3D spisg->status ? -EIO : 0; > - else > + } else { > + /* stop transfer */ > + regmap_write(spisg->map, SPISG_REG_DESC_LIST_H, 0); > ret =3D -ETIMEDOUT; > + } [Severity: High] Could this timeout path race with a late interrupt? By stopping the controller without synchronizing or masking the IRQ, a delayed interrupt might still arrive. If it does, aml_spisg_irq() unconditionally completes it: complete(&spisg->completion); If the SPI core immediately enqueues the next message, could this late interrupt prematurely complete the new transfer and prematurely unmap its active DMA buffers? [Severity: High] This is a pre-existing issue, but does the driver have an unbalanced clock reference count issue? The driver acquires clocks using devm_clk_get_enabled(), but manually disables them during error handling and removal. For example, in the error path of aml_spisg_probe(): out_clk: if (spisg->core) clk_disable_unprepare(spisg->core); clk_disable_unprepare(spisg->pclk); Since these are devm-managed clocks, the cleanup framework will also disable them, which results in a double-disable. Should these manual clk_disable_unprepare() calls be removed, or should the driver use the non-devm clock getters? --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260731-a9-spisg-v= 3-0-a15da3f70029@amlogic.com?part=3D2 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 69F7BC54F54 for ; Fri, 31 Jul 2026 09:22:18 +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=86mX1xhodW6+fnvxH5rOQPd9LejC3okg5GTg9i37YTc=; b=kD+upPxhfcofaW JM8uZHzG+mRAfRwImNkImctbgx3AfLYZm3C5vyKkl2vYfc5eqjhUR54VMQu+pwNAeaf/cIN6S+mf6 IRQssnzo/eVsYBkTnMcmlGWql6DuysdM6MvtN/duMLFwmxtWfZ/SuDXle+vB0bbLX2iHG7jVOrjbZ DHLLaXe2DqY2/wwX3R0V+yHD+67USgYspSlu0zBBwrSh+VQo1GChN4fOXyrR05bTWQoLoClirQaio 4ogEZrbIUAjvUafG5pLtgcLSL9FpsoUlqiFC/Omshoe5tSYCqQv21v5vw80MFUdaBeEtxnHJ/9K88 onF0h/IWWG26gK6+1wLg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wpjRX-0000000CB2k-3BNx; Fri, 31 Jul 2026 09:22:15 +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 1wpjRX-0000000CB2O-04Za for linux-amlogic@lists.infradead.org; Fri, 31 Jul 2026 09:22:15 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 42D90600AF; Fri, 31 Jul 2026 09:22:14 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9D5E71F000E9; Fri, 31 Jul 2026 09:22:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785489734; bh=buFpopr7n/hOL7T9hO29/5vNknhfH/3Ab58MQyljmVU=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=PQ9wmZYZ0e3z53BIcWXL6Hv1m51zsk/tZWysVjrp8Tu1a60lwX54+WTeUgdEFvy3E fHRv34OF0i2QBa5Lg/Hcza6gFkfcj2kggTCu1ozWnEwrtHaj9EE0+Dwphq2JFCni66 nM+Cie/vC/eQfJ77fmbcMkZHlPRY2jA0o5KONtU2mpHZt5osmAFZBCbaw/uS/yhHAP 5OhZgL11gUNdirAtWRKC/fdqrmXuolo25i5d7TzlEAWJqxL0tPi3r0BX21QTE4QBHh ZiykYOivKEcuGP3NqEzsKuGJNN4kPPUYZrq64Fppw1gtlQ4t4VSPnQ+FQKA4T73dfR Lf3yUc5QmDYIw== From: sashiko-bot@kernel.org Subject: Re: [PATCH v3 2/4] spi: amlogic: spisg: Fix transfer size limit and timeout handling To: "Xianwei Zhao" Cc: neil.armstrong@linaro.org, devicetree@vger.kernel.org, linux-amlogic@lists.infradead.org, robh@kernel.org, conor+dt@kernel.org In-Reply-To: <20260731-a9-spisg-v3-2-a15da3f70029@amlogic.com> References: <20260731-a9-spisg-v3-0-a15da3f70029@amlogic.com> <20260731-a9-spisg-v3-2-a15da3f70029@amlogic.com> Date: Fri, 31 Jul 2026 09:22:13 +0000 Message-Id: <20260731092213.9D5E71F000E9@smtp.kernel.org> X-BeenThere: linux-amlogic@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: 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-amlogic" Errors-To: linux-amlogic-bounces+linux-amlogic=archiver.kernel.org@lists.infradead.org VGhhbmsgeW91IGZvciB5b3VyIGNvbnRyaWJ1dGlvbiEgU2FzaGlrbyBBSSByZXZpZXcgZm91bmQg MyBwb3RlbnRpYWwgaXNzdWUocykgdG8gY29uc2lkZXI6CgpOZXcgaXNzdWVzOgotIFtIaWdoXSBU aGUgbmV3bHkgYWRkZWQgdGltZW91dCBhYm9ydCBwYXRoIHN0b3BzIHRoZSBjb250cm9sbGVyIGJ1 dCBmYWlscyB0byBzeW5jaHJvbml6ZSBvciBkaXNhYmxlIHBlbmRpbmcgaW50ZXJydXB0cywgY2F1 c2luZyBhIHJhY2UgY29uZGl0aW9uIHdoZXJlIGEgbGF0ZSBpbnRlcnJ1cHQgY2FuIGZhbHNlbHkg Y29tcGxldGUgYSBzdWJzZXF1ZW50IHRyYW5zZmVyLgoKUHJlLWV4aXN0aW5nIGlzc3VlczoKLSBb SGlnaF0gVHJhbnNmZXJzIGV4Y2VlZGluZyBTUElTR19CTE9DS19NQVggYmxvY2tzIGFyZSBzaWxl bnRseSB0cnVuY2F0ZWQgYnkgdGhlIGRyaXZlciBiZWNhdXNlIGl0IGNhcHMgdGhlIGJsb2NrIGNv dW50IGJ1dCBmYWlscyB0byBpbXBsZW1lbnQgdGhlIG1heF90cmFuc2Zlcl9zaXplIGNvbnRyb2xs ZXIgY2FsbGJhY2suCi0gW0hpZ2hdIFRoZSBkcml2ZXIgaW5jb3JyZWN0bHkgbWl4ZXMgYGRldm1f Y2xrX2dldF9lbmFibGVkKClgIHdpdGggbWFudWFsIGBjbGtfZGlzYWJsZV91bnByZXBhcmUoKWAg Y2FsbHMsIGxlYWRpbmcgdG8gdW5iYWxhbmNlZCBjbG9jayByZWZlcmVuY2UgY291bnRpbmcuCi0t CgotLS0gUGF0Y2ggWzJdOiBbUEFUQ0ggdjMgMi80XSBzcGk6IGFtbG9naWM6IHNwaXNnOiBGaXgg dHJhbnNmZXIgc2l6ZSBsaW1pdCBhbmQgdGltZW91dCBoYW5kbGluZyAtLS0KY29tbWl0IGYzNTk3 Nzc3ZjliM2FiMzI2ZmUwODY5OGZjZDkzODljNDU1ZTUzZDQKQXV0aG9yOiBYaWFud2VpIFpoYW8g PHhpYW53ZWkuemhhb0BhbWxvZ2ljLmNvbT4KCnNwaTogYW1sb2dpYzogc3Bpc2c6IEZpeCB0cmFu c2ZlciBzaXplIGxpbWl0IGFuZCB0aW1lb3V0IGhhbmRsaW5nCgpUaGUgY29tbWl0IHJlZHVjZXMg U1BJU0dfQkxPQ0tfTUFYIHRvIGF2b2lkIHplcm8tbGVuZ3RoIHRyYW5zZmVycyBhbmQgZml4ZXMK YSA2NC1iaXQgZGVsYXkgY2FsY3VsYXRpb24uIEl0IGFsc28gY2xlYXJzIHRoZSBkZXNjcmlwdG9y IGxpc3QgcmVnaXN0ZXIgb24gYQp0cmFuc2ZlciB0aW1lb3V0IHRvIHN0b3AgdGhlIGNvbnRyb2xs ZXIuCgo+IGRpZmYgLS1naXQgYS9kcml2ZXJzL3NwaS9zcGktYW1sb2dpYy1zcGlzZy5jIGIvZHJp dmVycy9zcGkvc3BpLWFtbG9naWMtc3Bpc2cuYwo+IC0tLSBhL2RyaXZlcnMvc3BpL3NwaS1hbWxv Z2ljLXNwaXNnLmMKPiArKysgYi9kcml2ZXJzL3NwaS9zcGktYW1sb2dpYy1zcGlzZy5jCj4gQEAg LTk1LDcgKzk1LDcgQEAKPiAgCj4gICNkZWZpbmUgU1BJU0dfTUFYX1JFRwkJCTB4NDAKPiAgCj4g LSNkZWZpbmUgU1BJU0dfQkxPQ0tfTUFYCQkJMHgxMDAwMDAKPiArI2RlZmluZSBTUElTR19CTE9D S19NQVgJCQkweEZGRkZGCgpbU2V2ZXJpdHk6IEhpZ2hdClRoaXMgaXNuJ3QgYSBidWcgaW50cm9k dWNlZCBieSB0aGlzIHBhdGNoLCBidXQgZG9lcyB0aGUgZHJpdmVyIHNpbGVudGx5CnRydW5jYXRl IGxhcmdlIHRyYW5zZmVycz8KCkluIGFtbF9zcGlzZ19wcm9iZSgpLCB0aGUgZHJpdmVyIHNldHMg Y3Rsci0+bWF4X2RtYV9sZW4gPSBTUElTR19CTE9DS19NQVgsCmJ1dCBpdCBkb2VzIG5vdCBpbXBs ZW1lbnQgdGhlIG1heF90cmFuc2Zlcl9zaXplIGNvbnRyb2xsZXIgY2FsbGJhY2suCgpXaGVuIGEg dHJhbnNmZXIgaXMgbGFyZ2VyIHRoYW4gU1BJU0dfQkxPQ0tfTUFYLCBhbWxfc3Bpc2dfc2V0dXBf dHJhbnNmZXIoKQpzaWxlbnRseSBjYXBzIGl0OgoKCWJsb2NrcyA9IG1pbl90KGludCwgYmxvY2tz LCBTUElTR19CTE9DS19NQVgpOwoKU2luY2UgdGhlIFNQSSBjb3JlIGlzbid0IGF3YXJlIG9mIHRo ZSBtYXhpbXVtIHRyYW5zZmVyIHNpemUgbGltaXQsIGl0IGNvdWxkCnN1Ym1pdCBvdmVyc2l6ZWQg dHJhbnNmZXJzIHRoYXQgZ2V0IHNpbGVudGx5IHRydW5jYXRlZC4gVGhpcyBjb3VsZCBsZWF2ZSBE TUEKYnVmZmVycyBwYXJ0aWFsbHkgdW5pbml0aWFsaXplZCBvbiBSWC4gU2hvdWxkIHdlIGltcGxl bWVudCB0aGUKY3Rsci0+bWF4X3RyYW5zZmVyX3NpemUgY2FsbGJhY2sgdG8gcHJldmVudCB0aGlz PwoKWyAuLi4gXQoKPiBAQCAtNTY1LDEwICs1NjUsMTMgQEAgc3RhdGljIGludCBhbWxfc3Bpc2df dHJhbnNmZXJfb25lX21lc3NhZ2Uoc3RydWN0IHNwaV9jb250cm9sbGVyICpjdGxyLAo+ICAJYW1s X3NwaXNnX3BlbmRpbmcoc3Bpc2csIGRlc2NzX3BhZGRyLCBmYWxzZSwgdHJ1ZSk7Cj4gIAlpZiAo d2FpdF9mb3JfY29tcGxldGlvbl90aW1lb3V0KCZzcGlzZy0+Y29tcGxldGlvbiwKPiAgCQkJCQlz cGlfY29udHJvbGxlcl9pc190YXJnZXQoc3Bpc2ctPmNvbnRyb2xsZXIpID8KPiAtCQkJCQlNQVhf U0NIRURVTEVfVElNRU9VVCA6IG1zZWNzX3RvX2ppZmZpZXMobXMpKSkKPiArCQkJCQlNQVhfU0NI RURVTEVfVElNRU9VVCA6IG1zZWNzX3RvX2ppZmZpZXMobXMpKSkgewo+ICAJCXJldCA9IHNwaXNn LT5zdGF0dXMgPyAtRUlPIDogMDsKPiAtCWVsc2UKPiArCX0gZWxzZSB7Cj4gKwkJLyogc3RvcCB0 cmFuc2ZlciAqLwo+ICsJCXJlZ21hcF93cml0ZShzcGlzZy0+bWFwLCBTUElTR19SRUdfREVTQ19M SVNUX0gsIDApOwo+ICAJCXJldCA9IC1FVElNRURPVVQ7Cj4gKwl9CgpbU2V2ZXJpdHk6IEhpZ2hd CkNvdWxkIHRoaXMgdGltZW91dCBwYXRoIHJhY2Ugd2l0aCBhIGxhdGUgaW50ZXJydXB0PwoKQnkg c3RvcHBpbmcgdGhlIGNvbnRyb2xsZXIgd2l0aG91dCBzeW5jaHJvbml6aW5nIG9yIG1hc2tpbmcg dGhlIElSUSwgYQpkZWxheWVkIGludGVycnVwdCBtaWdodCBzdGlsbCBhcnJpdmUuIElmIGl0IGRv ZXMsIGFtbF9zcGlzZ19pcnEoKQp1bmNvbmRpdGlvbmFsbHkgY29tcGxldGVzIGl0OgoKCWNvbXBs ZXRlKCZzcGlzZy0+Y29tcGxldGlvbik7CgpJZiB0aGUgU1BJIGNvcmUgaW1tZWRpYXRlbHkgZW5x dWV1ZXMgdGhlIG5leHQgbWVzc2FnZSwgY291bGQgdGhpcyBsYXRlCmludGVycnVwdCBwcmVtYXR1 cmVseSBjb21wbGV0ZSB0aGUgbmV3IHRyYW5zZmVyIGFuZCBwcmVtYXR1cmVseSB1bm1hcCBpdHMK YWN0aXZlIERNQSBidWZmZXJzPwoKW1NldmVyaXR5OiBIaWdoXQpUaGlzIGlzIGEgcHJlLWV4aXN0 aW5nIGlzc3VlLCBidXQgZG9lcyB0aGUgZHJpdmVyIGhhdmUgYW4gdW5iYWxhbmNlZCBjbG9jawpy ZWZlcmVuY2UgY291bnQgaXNzdWU/CgpUaGUgZHJpdmVyIGFjcXVpcmVzIGNsb2NrcyB1c2luZyBk ZXZtX2Nsa19nZXRfZW5hYmxlZCgpLCBidXQgbWFudWFsbHkKZGlzYWJsZXMgdGhlbSBkdXJpbmcg ZXJyb3IgaGFuZGxpbmcgYW5kIHJlbW92YWwuIEZvciBleGFtcGxlLCBpbiB0aGUgZXJyb3IKcGF0 aCBvZiBhbWxfc3Bpc2dfcHJvYmUoKToKCm91dF9jbGs6CglpZiAoc3Bpc2ctPmNvcmUpCgkJY2xr X2Rpc2FibGVfdW5wcmVwYXJlKHNwaXNnLT5jb3JlKTsKCWNsa19kaXNhYmxlX3VucHJlcGFyZShz cGlzZy0+cGNsayk7CgpTaW5jZSB0aGVzZSBhcmUgZGV2bS1tYW5hZ2VkIGNsb2NrcywgdGhlIGNs ZWFudXAgZnJhbWV3b3JrIHdpbGwgYWxzbwpkaXNhYmxlIHRoZW0sIHdoaWNoIHJlc3VsdHMgaW4g YSBkb3VibGUtZGlzYWJsZS4gU2hvdWxkIHRoZXNlIG1hbnVhbApjbGtfZGlzYWJsZV91bnByZXBh cmUoKSBjYWxscyBiZSByZW1vdmVkLCBvciBzaG91bGQgdGhlIGRyaXZlciB1c2UgdGhlCm5vbi1k ZXZtIGNsb2NrIGdldHRlcnM/CgotLSAKU2FzaGlrbyBBSSByZXZpZXcgwrcgaHR0cHM6Ly9zYXNo aWtvLmRldi8jL3BhdGNoc2V0LzIwMjYwNzMxLWE5LXNwaXNnLXYzLTAtYTE1ZGEzZjcwMDI5QGFt bG9naWMuY29tP3BhcnQ9MgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18KbGludXgtYW1sb2dpYyBtYWlsaW5nIGxpc3QKbGludXgtYW1sb2dpY0BsaXN0cy5p bmZyYWRlYWQub3JnCmh0dHA6Ly9saXN0cy5pbmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGluZm8v bGludXgtYW1sb2dpYwo=