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 189EA3290A5 for ; Tue, 8 Sep 2026 10:39:26 +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=1788863967; cv=none; b=mWcbEAtzntodXdXbcDCGX/OBn6yrw640iYMtPyqhVQTIJHZi6R6sx5kdFGEUEdoUNvIqTdXJmP8rGrPxmiEcR11CIvy2iRNuqovl9M/i5UiWD2pFYw6v7FXaZZKbu+PANmreUmjjQih6vgxwEEggQxtNRdt1bvTAwvj+BC+ge58= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788863967; c=relaxed/simple; bh=ZkWIEmMvDRrXW/o2cCknn5H4UIvxHIShHqe06WYRBP8=; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date: Message-Id; b=JgtyX3AATZvIf6a3DRZMnV3+eyYyjIrxb9h5gxtZBvuTZrRGEye5+C4fPcG1wDpOxR1gRrCk88KErYC/zqnPb9X6SZGpVAtuXHpch/ZRRFp6YlYyrLcj44/RMbLZoEXKS4NDioNAxL+bq88Gj7MRYL/F173RSPF10aCA8ZE/jpQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=FSQejPjY; 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="FSQejPjY" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 605631F00A3D; Tue, 8 Sep 2026 10:39:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788863965; bh=juJ4DzLhYeERpJWLTP8Alcr7dztbOTBzDRIhbo64Tk8=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=FSQejPjYrm3krgK95cXnMXshL+F3RaOB3FINbAYIfiFV1+ZdYZmtXKzkRDww43kL4 2gUGn3PDsnNX6i2uttpodkV68SqdKdVYn2L+qH5r68OqTgNpvrLd7x0WfuKlwGhmi4 npT9zOnf64trIgpXDVaCtO/5RPd3Vy6WIyYp0ERG++OZDtdSvoMyKcdPgMQTo8udW0 SlVKtxtjcWS8kyvNaENAr6+WC0c20pOnWWKr8XstkHlC84wsffH379UCHvBGWKoZwY wA+YyYRT3ibaA2bchdFZ8otqCDyvJ3bvGR3uDwTjgWv1EvMa16dJyTaxFVZ/9ZF7qE mzJ1FLvmm3sZQ== From: sashiko-bot@kernel.org Subject: Re: [PATCH] i3c: master: dw: Clamp GETMRL/GETMWL to controller FIFO limits Reply-To: sashiko-reviews@lists.linux.dev To: "Shubham Patil" Cc: Frank.Li@kernel.org, "Alexandre Belloni" , conor+dt@kernel.org, linux-i3c@lists.infradead.org, devicetree@vger.kernel.org, robh@kernel.org In-Reply-To: <20260908102724.3232660-1-shubhamsanjay.patil@amd.com> References: <20260908102724.3232660-1-shubhamsanjay.patil@amd.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 08 Sep 2026 10:39:24 +0000 Message-Id: <20260908103925.605631F00A3D@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 1 potential issue(= s) to consider: - [Medium] The commit message contradicts the implementation and inline com= ments regarding GET buffer updates on a failed SET command. -- commit 00d2a5b4dfc14cff243cee94eac37b1733ad5a1d Author: Shubham Patil i3c: master: dw: Clamp GETMRL/GETMWL to controller FIFO limits =20 The DW master rejects private SDR transfers larger than caps.datafifodepth with -EOPNOTSUPP. Targets often report MRL/MWL values larger than that FIFO, so the core stores limits the controller cannot meet. > After a successful GETMRL/GETMWL, issue Direct SETMRL/SETMWL to the > same target with lengths capped to the data FIFO (in bytes), then > rewrite the GET payload so the core keeps the same values. Only update > the GET buffer once SET is acked, so a failed SET does not leave the > core and the target disagreeing. [Severity: Medium] Is this commit message accurate? The implementation correctly updates the G= ET buffer regardless of the SET outcome to protect the controller's FIFO, matc= hing the inline comments, but this directly violates the claim here that the buf= fer is only updated if SET is acked. > diff --git a/drivers/i3c/master/dw-i3c-master.c b/drivers/i3c/master/dw-i= 3c-master.c > index 4563d8761ba0b..51defcb577619 100644 > --- a/drivers/i3c/master/dw-i3c-master.c > +++ b/drivers/i3c/master/dw-i3c-master.c [ ... ] > @@ -844,6 +850,130 @@ static int dw_i3c_ccc_get(struct dw_i3c_master *mas= ter, struct i3c_ccc_cmd *ccc) > +/* > + * Cap the limits a target reported through GETMRL to what this controll= er can > + * actually transfer, so the core never asks for a private read the data= FIFO > + * cannot hold. The optional IBI payload byte is capped to the IBI queue= depth > + * instead; since that byte is a u8, the IBI cap only ever applies to > + * controllers whose IBI queue is smaller than 255 bytes. > + * > + * Direct SETMRL is optional, so a target may implement GETMRL and NACK = the SET. > + * Clamp the values handed back to the core either way: a failed SET onl= y means > + * the target keeps its own larger limit, which is harmless as long as t= he core > + * stays within ours. > + */ > +static int dw_i3c_master_clamp_mrl(struct dw_i3c_master *master, > + struct i3c_ccc_cmd *ccc) > +{ [ ... ] > + ret =3D dw_i3c_ccc_set(master, &set_cmd); > + if (ret) > + dev_dbg(&master->base.dev, > + "SETMRL not accepted by target: %d\n", ret); > + > + if (clamp_read) { > + mrl->read_len =3D cpu_to_be16(max_fifo_bytes); > + dev_dbg(&master->base.dev, > + "clamped target MRL from %u to %u bytes (FIFO depth limit)\n", > + read_len, max_fifo_bytes); > + } [Severity: Medium] Could this update in dw_i3c_master_clamp_mrl() lead to developer confusion regarding core state synchronization? It updates the MRL buffer uncondition= ally after a potentially failed SET command, contrary to the commit message. [ ... ] > +static int dw_i3c_master_clamp_mwl(struct dw_i3c_master *master, > + struct i3c_ccc_cmd *ccc) > +{ [ ... ] > + ret =3D dw_i3c_ccc_set(master, &set_cmd); > + if (ret) > + dev_dbg(&master->base.dev, > + "SETMWL not accepted by target: %d\n", ret); > + > + mwl->len =3D cpu_to_be16(max_fifo_bytes); [Severity: Medium] Similarly, does this unconditional update in dw_i3c_master_clamp_mwl() need clarification in the commit message to avoid confusion about when the GET buffer is updated? --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260908102724.3232= 660-1-shubhamsanjay.patil@amd.com?part=3D1 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 608DBC79F82 for ; Tue, 8 Sep 2026 10:39: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=69X2MoHAnOOquAR7Q/B/2eNlc98FQy7ZU5ChXwz73/E=; b=RcTU/ydl4KacPC RKfgqbyELu7NQCIZvI6Ic6lyDLqjBRVFFYhrvihrtukgQQ6aHLpMIhHEFb26Ikd+KIQ9C69UTe3Bf M4iNaPOr4JW8qNq1U7rR416bTJ0xO4glLKQpxVDYMqzJOkQlpZtaRO9llCjYwDSrX4ynEa75RbKLY ilrasHeao9hp1Si8UBFnxE/DcC9hvI2/99Fqi1xKBh9X6uIwmh+EcqELu5w0pPD/WteyBO9b9qj4A ZktUBG9tXmjjgjUdDy4OMM8HbCvB8lwlzx+SxDTXGU0qXx4gpt4ItrevZV1Fscg4JGkzLg8nXtjvr mA0KCFJ7uoNs94FVCXIA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1x3tEd-00000008nCy-0ZM0; Tue, 08 Sep 2026 10:39: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 1x3tEc-00000008nCl-174a for linux-i3c@lists.infradead.org; Tue, 08 Sep 2026 10:39:26 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id D51AB41688; Tue, 8 Sep 2026 10:39:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 605631F00A3D; Tue, 8 Sep 2026 10:39:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788863965; bh=juJ4DzLhYeERpJWLTP8Alcr7dztbOTBzDRIhbo64Tk8=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=FSQejPjYrm3krgK95cXnMXshL+F3RaOB3FINbAYIfiFV1+ZdYZmtXKzkRDww43kL4 2gUGn3PDsnNX6i2uttpodkV68SqdKdVYn2L+qH5r68OqTgNpvrLd7x0WfuKlwGhmi4 npT9zOnf64trIgpXDVaCtO/5RPd3Vy6WIyYp0ERG++OZDtdSvoMyKcdPgMQTo8udW0 SlVKtxtjcWS8kyvNaENAr6+WC0c20pOnWWKr8XstkHlC84wsffH379UCHvBGWKoZwY wA+YyYRT3ibaA2bchdFZ8otqCDyvJ3bvGR3uDwTjgWv1EvMa16dJyTaxFVZ/9ZF7qE mzJ1FLvmm3sZQ== From: sashiko-bot@kernel.org Subject: Re: [PATCH] i3c: master: dw: Clamp GETMRL/GETMWL to controller FIFO limits To: "Shubham Patil" Cc: Frank.Li@kernel.org, "Alexandre Belloni" , conor+dt@kernel.org, linux-i3c@lists.infradead.org, devicetree@vger.kernel.org, robh@kernel.org In-Reply-To: <20260908102724.3232660-1-shubhamsanjay.patil@amd.com> References: <20260908102724.3232660-1-shubhamsanjay.patil@amd.com> Date: Tue, 08 Sep 2026 10:39:24 +0000 Message-Id: <20260908103925.605631F00A3D@smtp.kernel.org> X-BeenThere: linux-i3c@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-i3c" Errors-To: linux-i3c-bounces+linux-i3c=archiver.kernel.org@lists.infradead.org VGhhbmsgeW91IGZvciB5b3VyIGNvbnRyaWJ1dGlvbiEgU2FzaGlrbyBBSSByZXZpZXcgZm91bmQg MSBwb3RlbnRpYWwgaXNzdWUocykgdG8gY29uc2lkZXI6Ci0gW01lZGl1bV0gVGhlIGNvbW1pdCBt ZXNzYWdlIGNvbnRyYWRpY3RzIHRoZSBpbXBsZW1lbnRhdGlvbiBhbmQgaW5saW5lIGNvbW1lbnRz IHJlZ2FyZGluZyBHRVQgYnVmZmVyIHVwZGF0ZXMgb24gYSBmYWlsZWQgU0VUIGNvbW1hbmQuCi0t Cgpjb21taXQgMDBkMmE1YjRkZmMxNGNmZjI0M2NlZTk0ZWFjMzdiMTczM2FkNWExZApBdXRob3I6 IFNodWJoYW0gUGF0aWwgPHNodWJoYW1zYW5qYXkucGF0aWxAYW1kLmNvbT4KCmkzYzogbWFzdGVy OiBkdzogQ2xhbXAgR0VUTVJML0dFVE1XTCB0byBjb250cm9sbGVyIEZJRk8gbGltaXRzCiAgICAK VGhlIERXIG1hc3RlciByZWplY3RzIHByaXZhdGUgU0RSIHRyYW5zZmVycyBsYXJnZXIgdGhhbiBj YXBzLmRhdGFmaWZvZGVwdGgKd2l0aCAtRU9QTk9UU1VQUC4gVGFyZ2V0cyBvZnRlbiByZXBvcnQg TVJML01XTCB2YWx1ZXMgbGFyZ2VyIHRoYW4gdGhhdApGSUZPLCBzbyB0aGUgY29yZSBzdG9yZXMg bGltaXRzIHRoZSBjb250cm9sbGVyIGNhbm5vdCBtZWV0LgoKPiBBZnRlciBhIHN1Y2Nlc3NmdWwg R0VUTVJML0dFVE1XTCwgaXNzdWUgRGlyZWN0IFNFVE1STC9TRVRNV0wgdG8gdGhlCj4gc2FtZSB0 YXJnZXQgd2l0aCBsZW5ndGhzIGNhcHBlZCB0byB0aGUgZGF0YSBGSUZPIChpbiBieXRlcyksIHRo ZW4KPiByZXdyaXRlIHRoZSBHRVQgcGF5bG9hZCBzbyB0aGUgY29yZSBrZWVwcyB0aGUgc2FtZSB2 YWx1ZXMuIE9ubHkgdXBkYXRlCj4gdGhlIEdFVCBidWZmZXIgb25jZSBTRVQgaXMgYWNrZWQsIHNv IGEgZmFpbGVkIFNFVCBkb2VzIG5vdCBsZWF2ZSB0aGUKPiBjb3JlIGFuZCB0aGUgdGFyZ2V0IGRp c2FncmVlaW5nLgoKW1NldmVyaXR5OiBNZWRpdW1dCklzIHRoaXMgY29tbWl0IG1lc3NhZ2UgYWNj dXJhdGU/IFRoZSBpbXBsZW1lbnRhdGlvbiBjb3JyZWN0bHkgdXBkYXRlcyB0aGUgR0VUCmJ1ZmZl ciByZWdhcmRsZXNzIG9mIHRoZSBTRVQgb3V0Y29tZSB0byBwcm90ZWN0IHRoZSBjb250cm9sbGVy J3MgRklGTywgbWF0Y2hpbmcKdGhlIGlubGluZSBjb21tZW50cywgYnV0IHRoaXMgZGlyZWN0bHkg dmlvbGF0ZXMgdGhlIGNsYWltIGhlcmUgdGhhdCB0aGUgYnVmZmVyCmlzIG9ubHkgdXBkYXRlZCBp ZiBTRVQgaXMgYWNrZWQuCgo+IGRpZmYgLS1naXQgYS9kcml2ZXJzL2kzYy9tYXN0ZXIvZHctaTNj LW1hc3Rlci5jIGIvZHJpdmVycy9pM2MvbWFzdGVyL2R3LWkzYy1tYXN0ZXIuYwo+IGluZGV4IDQ1 NjNkODc2MWJhMGIuLjUxZGVmY2I1Nzc2MTkgMTAwNjQ0Cj4gLS0tIGEvZHJpdmVycy9pM2MvbWFz dGVyL2R3LWkzYy1tYXN0ZXIuYwo+ICsrKyBiL2RyaXZlcnMvaTNjL21hc3Rlci9kdy1pM2MtbWFz dGVyLmMKWyAuLi4gXQo+IEBAIC04NDQsNiArODUwLDEzMCBAQCBzdGF0aWMgaW50IGR3X2kzY19j Y2NfZ2V0KHN0cnVjdCBkd19pM2NfbWFzdGVyICptYXN0ZXIsIHN0cnVjdCBpM2NfY2NjX2NtZCAq Y2NjKQo+ICsvKgo+ICsgKiBDYXAgdGhlIGxpbWl0cyBhIHRhcmdldCByZXBvcnRlZCB0aHJvdWdo IEdFVE1STCB0byB3aGF0IHRoaXMgY29udHJvbGxlciBjYW4KPiArICogYWN0dWFsbHkgdHJhbnNm ZXIsIHNvIHRoZSBjb3JlIG5ldmVyIGFza3MgZm9yIGEgcHJpdmF0ZSByZWFkIHRoZSBkYXRhIEZJ Rk8KPiArICogY2Fubm90IGhvbGQuIFRoZSBvcHRpb25hbCBJQkkgcGF5bG9hZCBieXRlIGlzIGNh cHBlZCB0byB0aGUgSUJJIHF1ZXVlIGRlcHRoCj4gKyAqIGluc3RlYWQ7IHNpbmNlIHRoYXQgYnl0 ZSBpcyBhIHU4LCB0aGUgSUJJIGNhcCBvbmx5IGV2ZXIgYXBwbGllcyB0bwo+ICsgKiBjb250cm9s bGVycyB3aG9zZSBJQkkgcXVldWUgaXMgc21hbGxlciB0aGFuIDI1NSBieXRlcy4KPiArICoKPiAr ICogRGlyZWN0IFNFVE1STCBpcyBvcHRpb25hbCwgc28gYSB0YXJnZXQgbWF5IGltcGxlbWVudCBH RVRNUkwgYW5kIE5BQ0sgdGhlIFNFVC4KPiArICogQ2xhbXAgdGhlIHZhbHVlcyBoYW5kZWQgYmFj ayB0byB0aGUgY29yZSBlaXRoZXIgd2F5OiBhIGZhaWxlZCBTRVQgb25seSBtZWFucwo+ICsgKiB0 aGUgdGFyZ2V0IGtlZXBzIGl0cyBvd24gbGFyZ2VyIGxpbWl0LCB3aGljaCBpcyBoYXJtbGVzcyBh cyBsb25nIGFzIHRoZSBjb3JlCj4gKyAqIHN0YXlzIHdpdGhpbiBvdXJzLgo+ICsgKi8KPiArc3Rh dGljIGludCBkd19pM2NfbWFzdGVyX2NsYW1wX21ybChzdHJ1Y3QgZHdfaTNjX21hc3RlciAqbWFz dGVyLAo+ICsJCQkJICAgc3RydWN0IGkzY19jY2NfY21kICpjY2MpCj4gK3sKWyAuLi4gXQo+ICsJ cmV0ID0gZHdfaTNjX2NjY19zZXQobWFzdGVyLCAmc2V0X2NtZCk7Cj4gKwlpZiAocmV0KQo+ICsJ CWRldl9kYmcoJm1hc3Rlci0+YmFzZS5kZXYsCj4gKwkJCSJTRVRNUkwgbm90IGFjY2VwdGVkIGJ5 IHRhcmdldDogJWRcbiIsIHJldCk7Cj4gKwo+ICsJaWYgKGNsYW1wX3JlYWQpIHsKPiArCQltcmwt PnJlYWRfbGVuID0gY3B1X3RvX2JlMTYobWF4X2ZpZm9fYnl0ZXMpOwo+ICsJCWRldl9kYmcoJm1h c3Rlci0+YmFzZS5kZXYsCj4gKwkJCSJjbGFtcGVkIHRhcmdldCBNUkwgZnJvbSAldSB0byAldSBi eXRlcyAoRklGTyBkZXB0aCBsaW1pdClcbiIsCj4gKwkJCXJlYWRfbGVuLCBtYXhfZmlmb19ieXRl cyk7Cj4gKwl9CgpbU2V2ZXJpdHk6IE1lZGl1bV0KQ291bGQgdGhpcyB1cGRhdGUgaW4gZHdfaTNj X21hc3Rlcl9jbGFtcF9tcmwoKSBsZWFkIHRvIGRldmVsb3BlciBjb25mdXNpb24KcmVnYXJkaW5n IGNvcmUgc3RhdGUgc3luY2hyb25pemF0aW9uPyBJdCB1cGRhdGVzIHRoZSBNUkwgYnVmZmVyIHVu Y29uZGl0aW9uYWxseQphZnRlciBhIHBvdGVudGlhbGx5IGZhaWxlZCBTRVQgY29tbWFuZCwgY29u dHJhcnkgdG8gdGhlIGNvbW1pdCBtZXNzYWdlLgoKWyAuLi4gXQo+ICtzdGF0aWMgaW50IGR3X2kz Y19tYXN0ZXJfY2xhbXBfbXdsKHN0cnVjdCBkd19pM2NfbWFzdGVyICptYXN0ZXIsCj4gKwkJCQkg ICBzdHJ1Y3QgaTNjX2NjY19jbWQgKmNjYykKPiArewpbIC4uLiBdCj4gKwlyZXQgPSBkd19pM2Nf Y2NjX3NldChtYXN0ZXIsICZzZXRfY21kKTsKPiArCWlmIChyZXQpCj4gKwkJZGV2X2RiZygmbWFz dGVyLT5iYXNlLmRldiwKPiArCQkJIlNFVE1XTCBub3QgYWNjZXB0ZWQgYnkgdGFyZ2V0OiAlZFxu IiwgcmV0KTsKPiArCj4gKwltd2wtPmxlbiA9IGNwdV90b19iZTE2KG1heF9maWZvX2J5dGVzKTsK CltTZXZlcml0eTogTWVkaXVtXQpTaW1pbGFybHksIGRvZXMgdGhpcyB1bmNvbmRpdGlvbmFsIHVw ZGF0ZSBpbiBkd19pM2NfbWFzdGVyX2NsYW1wX213bCgpIG5lZWQKY2xhcmlmaWNhdGlvbiBpbiB0 aGUgY29tbWl0IG1lc3NhZ2UgdG8gYXZvaWQgY29uZnVzaW9uIGFib3V0IHdoZW4gdGhlIEdFVApi dWZmZXIgaXMgdXBkYXRlZD8KCi0tIApTYXNoaWtvIEFJIHJldmlldyDCtyBodHRwczovL3Nhc2hp a28uZGV2LyMvcGF0Y2hzZXQvMjAyNjA5MDgxMDI3MjQuMzIzMjY2MC0xLXNodWJoYW1zYW5qYXku cGF0aWxAYW1kLmNvbT9wYXJ0PTEKCi0tIApsaW51eC1pM2MgbWFpbGluZyBsaXN0CmxpbnV4LWkz Y0BsaXN0cy5pbmZyYWRlYWQub3JnCmh0dHA6Ly9saXN0cy5pbmZyYWRlYWQub3JnL21haWxtYW4v bGlzdGluZm8vbGludXgtaTNjCg==