From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Kerr Date: Sun, 26 Feb 2023 15:04:16 +0800 Subject: [PATCH v6 1/2] dt-bindings: i2c: aspeed: support for AST2600-i2cv2 In-Reply-To: <20230226031321.3126756-2-ryan_chen@aspeedtech.com> References: <20230226031321.3126756-1-ryan_chen@aspeedtech.com> <20230226031321.3126756-2-ryan_chen@aspeedtech.com> Message-ID: <8999ef4a57b035a81b086d8732d119638d46968c.camel@codeconstruct.com.au> List-Id: To: linux-aspeed@lists.ozlabs.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Ryan, > --- a/Documentation/devicetree/bindings/i2c/aspeed,i2c.yaml > +++ b/Documentation/devicetree/bindings/i2c/aspeed,i2c.yaml > @@ -49,6 +49,25 @@ properties: > ???? description: > ?????? states that there is another master active on this bus > ? > +? aspeed,timeout: > +??? type: boolean > +??? description: I2C bus timeout enable for master/slave mode > + > +? aspeed,xfer-mode: > +??? description: | > +????? I2C bus transfer mode selection. > +????? - "byte": I2C bus byte transfer mode. > +????? - "buffered": I2C bus buffer register transfer mode. > +????? - "dma": I2C bus dma transfer mode (default) > +??? items: > +????? enum: [byte, buffered, dma] > +??? maxItems: 1 > +??? $ref: /schemas/types.yaml#/definitions/non-unique-string-array There are still unresolved questions about this xfer-mode property from previous submissions of this binding. We don't yet have a justification on why the mode configuration is needed in the device tree rather than something that is specified in a driver implementation. By now, I think we well understand what the modes are, and how a driver implementation might configure them, but none of that has (so far) provided sufficient rationale on why this belongs in the device tree. The previous threads had a couple of pending discussions, following up on those here: A) You mentioned in [1] that the DMA controller is shared between all i3c devices, does that have any consequence on which modes individual devices might want to choose? B) You implied in [2] that the different transfer modes might be related to whether there are other masters present on the bus, but the logic behind that is not clear. C) In [3] you mentioned that there might be some DRAM savings by using a particular mode. and, most importantly: D) unanswered from [4] and [5]: what are the hardware-specified reasons why a DT author would chose one mode over another? If you can write this out in some format like: - in hardware situation X, you should use DMA mode - in hardware situation Y, you should use byte mode - [...] that might help us to understand where this configuration belongs, or what a reasonable DT representation should look like, or even if existing DT schema can already provide the information required to decide. Cheers, Jeremy [1]: https://lists.ozlabs.org/pipermail/linux-aspeed/2023-February/009876.html [2]: https://lists.ozlabs.org/pipermail/linux-aspeed/2023-February/009892.html [3]: https://lists.ozlabs.org/pipermail/linux-aspeed/2023-February/009880.html [4]: https://lists.ozlabs.org/pipermail/linux-aspeed/2023-February/009871.html [5]: https://lists.ozlabs.org/pipermail/linux-aspeed/2023-February/009884.html 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0D92AC64ED6 for ; Sun, 26 Feb 2023 07:04:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229524AbjBZHE2 (ORCPT ); Sun, 26 Feb 2023 02:04:28 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43920 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229379AbjBZHE1 (ORCPT ); Sun, 26 Feb 2023 02:04:27 -0500 Received: from codeconstruct.com.au (pi.codeconstruct.com.au [203.29.241.158]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 87A80E06D; Sat, 25 Feb 2023 23:04:25 -0800 (PST) Received: from sparky.lan (unknown [159.196.93.152]) by mail.codeconstruct.com.au (Postfix) with ESMTPSA id 1BD3A2022A; Sun, 26 Feb 2023 15:04:17 +0800 (AWST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codeconstruct.com.au; s=2022a; t=1677395063; bh=Y7NTv+s/hWLeamtCbWmhn/7LKRoNqR/n38OfE9hBxlM=; h=Subject:From:To:Date:In-Reply-To:References; b=eRUwOOoHuKdrRpkN6k32TqeYuPJ2qpo8OHbVCzKlNi0EcrDheEyrUr7y8e7GJXNED PQwzOSmmsOInezLa2c5lLpi0j0qRe3tda/GrHsp2InsAdUhXEerdjAFXxWoH3gbzHx dDYrnKPJZbqCtAng1kR86tfWvHG2oOa/oQ++PKP+19xVZuawP0azjT98V5dNiTSadq 8v3A5ynMhOdk7FvEZgoSv2pABRqqkeW8E9fVYdE31uRXt2MdT0XYrVjXoNgBFxY/g5 m8O0EWEC04qfEIQ3kBcIl0LGlDNYvh+ThCamAIPZWrpyTkS307I3ZcU/ECJeppcfGd 6BwTzPiVu4NkQ== Message-ID: <8999ef4a57b035a81b086d8732d119638d46968c.camel@codeconstruct.com.au> Subject: Re: [PATCH v6 1/2] dt-bindings: i2c: aspeed: support for AST2600-i2cv2 From: Jeremy Kerr To: Ryan Chen , Andrew Jeffery , Brendan Higgins , Benjamin Herrenschmidt , Joel Stanley , Rob Herring , Krzysztof Kozlowski , Philipp Zabel , linux-i2c@vger.kernel.org, openbmc@lists.ozlabs.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org Date: Sun, 26 Feb 2023 15:04:16 +0800 In-Reply-To: <20230226031321.3126756-2-ryan_chen@aspeedtech.com> References: <20230226031321.3126756-1-ryan_chen@aspeedtech.com> <20230226031321.3126756-2-ryan_chen@aspeedtech.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.4-1 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-i2c@vger.kernel.org Hi Ryan, > --- a/Documentation/devicetree/bindings/i2c/aspeed,i2c.yaml > +++ b/Documentation/devicetree/bindings/i2c/aspeed,i2c.yaml > @@ -49,6 +49,25 @@ properties: > =C2=A0=C2=A0=C2=A0=C2=A0 description: > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 states that there is another master = active on this bus > =C2=A0 > +=C2=A0 aspeed,timeout: > +=C2=A0=C2=A0=C2=A0 type: boolean > +=C2=A0=C2=A0=C2=A0 description: I2C bus timeout enable for master/slave = mode > + > +=C2=A0 aspeed,xfer-mode: > +=C2=A0=C2=A0=C2=A0 description: | > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I2C bus transfer mode selection. > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - "byte": I2C bus byte transfer mode. > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - "buffered": I2C bus buffer register tra= nsfer mode. > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - "dma": I2C bus dma transfer mode (defau= lt) > +=C2=A0=C2=A0=C2=A0 items: > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 enum: [byte, buffered, dma] > +=C2=A0=C2=A0=C2=A0 maxItems: 1 > +=C2=A0=C2=A0=C2=A0 $ref: /schemas/types.yaml#/definitions/non-unique-str= ing-array There are still unresolved questions about this xfer-mode property from previous submissions of this binding. We don't yet have a justification on why the mode configuration is needed in the device tree rather than something that is specified in a driver implementation. By now, I think we well understand what the modes are, and how a driver implementation might configure them, but none of that has (so far) provided sufficient rationale on why this belongs in the device tree. The previous threads had a couple of pending discussions, following up on those here: A) You mentioned in [1] that the DMA controller is shared between all i3c devices, does that have any consequence on which modes individual devices might want to choose? B) You implied in [2] that the different transfer modes might be related to whether there are other masters present on the bus, but the logic behind that is not clear. C) In [3] you mentioned that there might be some DRAM savings by using a particular mode. and, most importantly: D) unanswered from [4] and [5]: what are the hardware-specified reasons why a DT author would chose one mode over another? If you can write this out in some format like: - in hardware situation X, you should use DMA mode - in hardware situation Y, you should use byte mode - [...] that might help us to understand where this configuration belongs, or what a reasonable DT representation should look like, or even if existing DT schema can already provide the information required to decide. Cheers, Jeremy [1]: https://lists.ozlabs.org/pipermail/linux-aspeed/2023-February/009876.h= tml [2]: https://lists.ozlabs.org/pipermail/linux-aspeed/2023-February/009892.h= tml [3]: https://lists.ozlabs.org/pipermail/linux-aspeed/2023-February/009880.h= tml [4]: https://lists.ozlabs.org/pipermail/linux-aspeed/2023-February/009871.h= tml [5]: https://lists.ozlabs.org/pipermail/linux-aspeed/2023-February/009884.h= tml 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 6A818C6FA8E for ; Sun, 26 Feb 2023 07:05:44 +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:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Date:To:From:Subject:Message-ID:Reply-To:Cc:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=MTR4i8Qvgai3H2wXrtJ0iW13RTSj1UDPEdF+tAaqSR4=; b=DrznpZQyx4wV38 DsbUy6/X4Djlu/WX+ZxuglnBe3nGwzV9bALB2KWg86eynoWn+qAq39sSVFheAIHTpjdvhUN6EXQed QeRoKONg/4NYb24/4IvoYZFtRYJItJyugN8OeD64eIHqeVXXqFQNLttIPKAl81XjZkVUEh4nvoY1Z L0pQkRu9/IAsRwPyLIaskgOeB0ttzYu8ehdHgs3focRitC91qctqeTbOWYEygisOWgbMrsJsc/K5e VK1b+Gjwp8q5mEzZ+LDd2ARsN86eZz2fqW2nJSOOjuRY+F/OOJWrhAz+CDrQxGxwwLtiNswKj1kGZ oaqawRdTtlQpbtCZBqqw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pWB5F-006wgT-Cy; Sun, 26 Feb 2023 07:04:33 +0000 Received: from pi.codeconstruct.com.au ([203.29.241.158] helo=codeconstruct.com.au) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pWB5B-006wfs-Ik for linux-arm-kernel@lists.infradead.org; Sun, 26 Feb 2023 07:04:31 +0000 Received: from sparky.lan (unknown [159.196.93.152]) by mail.codeconstruct.com.au (Postfix) with ESMTPSA id 1BD3A2022A; Sun, 26 Feb 2023 15:04:17 +0800 (AWST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codeconstruct.com.au; s=2022a; t=1677395063; bh=Y7NTv+s/hWLeamtCbWmhn/7LKRoNqR/n38OfE9hBxlM=; h=Subject:From:To:Date:In-Reply-To:References; b=eRUwOOoHuKdrRpkN6k32TqeYuPJ2qpo8OHbVCzKlNi0EcrDheEyrUr7y8e7GJXNED PQwzOSmmsOInezLa2c5lLpi0j0qRe3tda/GrHsp2InsAdUhXEerdjAFXxWoH3gbzHx dDYrnKPJZbqCtAng1kR86tfWvHG2oOa/oQ++PKP+19xVZuawP0azjT98V5dNiTSadq 8v3A5ynMhOdk7FvEZgoSv2pABRqqkeW8E9fVYdE31uRXt2MdT0XYrVjXoNgBFxY/g5 m8O0EWEC04qfEIQ3kBcIl0LGlDNYvh+ThCamAIPZWrpyTkS307I3ZcU/ECJeppcfGd 6BwTzPiVu4NkQ== Message-ID: <8999ef4a57b035a81b086d8732d119638d46968c.camel@codeconstruct.com.au> Subject: Re: [PATCH v6 1/2] dt-bindings: i2c: aspeed: support for AST2600-i2cv2 From: Jeremy Kerr To: Ryan Chen , Andrew Jeffery , Brendan Higgins , Benjamin Herrenschmidt , Joel Stanley , Rob Herring , Krzysztof Kozlowski , Philipp Zabel , linux-i2c@vger.kernel.org, openbmc@lists.ozlabs.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org Date: Sun, 26 Feb 2023 15:04:16 +0800 In-Reply-To: <20230226031321.3126756-2-ryan_chen@aspeedtech.com> References: <20230226031321.3126756-1-ryan_chen@aspeedtech.com> <20230226031321.3126756-2-ryan_chen@aspeedtech.com> User-Agent: Evolution 3.46.4-1 MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230225_230429_833999_A300B353 X-CRM114-Status: GOOD ( 12.94 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org SGkgUnlhbiwKCj4gLS0tIGEvRG9jdW1lbnRhdGlvbi9kZXZpY2V0cmVlL2JpbmRpbmdzL2kyYy9h c3BlZWQsaTJjLnlhbWwKPiArKysgYi9Eb2N1bWVudGF0aW9uL2RldmljZXRyZWUvYmluZGluZ3Mv aTJjL2FzcGVlZCxpMmMueWFtbAo+IEBAIC00OSw2ICs0OSwyNSBAQCBwcm9wZXJ0aWVzOgo+IMKg wqDCoMKgIGRlc2NyaXB0aW9uOgo+IMKgwqDCoMKgwqDCoCBzdGF0ZXMgdGhhdCB0aGVyZSBpcyBh bm90aGVyIG1hc3RlciBhY3RpdmUgb24gdGhpcyBidXMKPiDCoAo+ICvCoCBhc3BlZWQsdGltZW91 dDoKPiArwqDCoMKgIHR5cGU6IGJvb2xlYW4KPiArwqDCoMKgIGRlc2NyaXB0aW9uOiBJMkMgYnVz IHRpbWVvdXQgZW5hYmxlIGZvciBtYXN0ZXIvc2xhdmUgbW9kZQo+ICsKPiArwqAgYXNwZWVkLHhm ZXItbW9kZToKPiArwqDCoMKgIGRlc2NyaXB0aW9uOiB8Cj4gK8KgwqDCoMKgwqAgSTJDIGJ1cyB0 cmFuc2ZlciBtb2RlIHNlbGVjdGlvbi4KPiArwqDCoMKgwqDCoCAtICJieXRlIjogSTJDIGJ1cyBi eXRlIHRyYW5zZmVyIG1vZGUuCj4gK8KgwqDCoMKgwqAgLSAiYnVmZmVyZWQiOiBJMkMgYnVzIGJ1 ZmZlciByZWdpc3RlciB0cmFuc2ZlciBtb2RlLgo+ICvCoMKgwqDCoMKgIC0gImRtYSI6IEkyQyBi dXMgZG1hIHRyYW5zZmVyIG1vZGUgKGRlZmF1bHQpCj4gK8KgwqDCoCBpdGVtczoKPiArwqDCoMKg wqDCoCBlbnVtOiBbYnl0ZSwgYnVmZmVyZWQsIGRtYV0KPiArwqDCoMKgIG1heEl0ZW1zOiAxCj4g K8KgwqDCoCAkcmVmOiAvc2NoZW1hcy90eXBlcy55YW1sIy9kZWZpbml0aW9ucy9ub24tdW5pcXVl LXN0cmluZy1hcnJheQoKVGhlcmUgYXJlIHN0aWxsIHVucmVzb2x2ZWQgcXVlc3Rpb25zIGFib3V0 IHRoaXMgeGZlci1tb2RlIHByb3BlcnR5IGZyb20KcHJldmlvdXMgc3VibWlzc2lvbnMgb2YgdGhp cyBiaW5kaW5nLiBXZSBkb24ndCB5ZXQgaGF2ZSBhIGp1c3RpZmljYXRpb24Kb24gd2h5IHRoZSBt b2RlIGNvbmZpZ3VyYXRpb24gaXMgbmVlZGVkIGluIHRoZSBkZXZpY2UgdHJlZSByYXRoZXIgdGhh bgpzb21ldGhpbmcgdGhhdCBpcyBzcGVjaWZpZWQgaW4gYSBkcml2ZXIgaW1wbGVtZW50YXRpb24u CgpCeSBub3csIEkgdGhpbmsgd2Ugd2VsbCB1bmRlcnN0YW5kIHdoYXQgdGhlIG1vZGVzIGFyZSwg YW5kIGhvdyBhIGRyaXZlcgppbXBsZW1lbnRhdGlvbiBtaWdodCBjb25maWd1cmUgdGhlbSwgYnV0 IG5vbmUgb2YgdGhhdCBoYXMgKHNvIGZhcikKcHJvdmlkZWQgc3VmZmljaWVudCByYXRpb25hbGUg b24gd2h5IHRoaXMgYmVsb25ncyBpbiB0aGUgZGV2aWNlIHRyZWUuCgpUaGUgcHJldmlvdXMgdGhy ZWFkcyBoYWQgYSBjb3VwbGUgb2YgcGVuZGluZyBkaXNjdXNzaW9ucywgZm9sbG93aW5nIHVwIG9u CnRob3NlIGhlcmU6CgpBKSBZb3UgbWVudGlvbmVkIGluIFsxXSB0aGF0IHRoZSBETUEgY29udHJv bGxlciBpcyBzaGFyZWQgYmV0d2VlbiBhbGwgaTNjCmRldmljZXMsIGRvZXMgdGhhdCBoYXZlIGFu eSBjb25zZXF1ZW5jZSBvbiB3aGljaCBtb2RlcyBpbmRpdmlkdWFsCmRldmljZXMgbWlnaHQgd2Fu dCB0byBjaG9vc2U/CgpCKSBZb3UgaW1wbGllZCBpbiBbMl0gdGhhdCB0aGUgZGlmZmVyZW50IHRy YW5zZmVyIG1vZGVzIG1pZ2h0IGJlIHJlbGF0ZWQKdG8gd2hldGhlciB0aGVyZSBhcmUgb3RoZXIg bWFzdGVycyBwcmVzZW50IG9uIHRoZSBidXMsIGJ1dCB0aGUgbG9naWMKYmVoaW5kIHRoYXQgaXMg bm90IGNsZWFyLgoKQykgSW4gWzNdIHlvdSBtZW50aW9uZWQgdGhhdCB0aGVyZSBtaWdodCBiZSBz b21lIERSQU0gc2F2aW5ncyBieSB1c2luZyBhCnBhcnRpY3VsYXIgbW9kZS4KCmFuZCwgbW9zdCBp bXBvcnRhbnRseToKCkQpIHVuYW5zd2VyZWQgZnJvbSBbNF0gYW5kIFs1XTogd2hhdCBhcmUgdGhl IGhhcmR3YXJlLXNwZWNpZmllZCByZWFzb25zCndoeSBhIERUIGF1dGhvciB3b3VsZCBjaG9zZSBv bmUgbW9kZSBvdmVyIGFub3RoZXI/CgpJZiB5b3UgY2FuIHdyaXRlIHRoaXMgb3V0IGluIHNvbWUg Zm9ybWF0IGxpa2U6CgogLSBpbiBoYXJkd2FyZSBzaXR1YXRpb24gWCwgeW91IHNob3VsZCB1c2Ug RE1BIG1vZGUKIC0gaW4gaGFyZHdhcmUgc2l0dWF0aW9uIFksIHlvdSBzaG91bGQgdXNlIGJ5dGUg bW9kZQogLSBbLi4uXQoKdGhhdCBtaWdodCBoZWxwIHVzIHRvIHVuZGVyc3RhbmQgd2hlcmUgdGhp cyBjb25maWd1cmF0aW9uIGJlbG9uZ3MsIG9yCndoYXQgYSByZWFzb25hYmxlIERUIHJlcHJlc2Vu dGF0aW9uIHNob3VsZCBsb29rIGxpa2UsIG9yIGV2ZW4gaWYKZXhpc3RpbmcgRFQgc2NoZW1hIGNh biBhbHJlYWR5IHByb3ZpZGUgdGhlIGluZm9ybWF0aW9uIHJlcXVpcmVkIHRvCmRlY2lkZS4KCkNo ZWVycywKCgpKZXJlbXkKClsxXTogaHR0cHM6Ly9saXN0cy5vemxhYnMub3JnL3BpcGVybWFpbC9s aW51eC1hc3BlZWQvMjAyMy1GZWJydWFyeS8wMDk4NzYuaHRtbApbMl06IGh0dHBzOi8vbGlzdHMu b3psYWJzLm9yZy9waXBlcm1haWwvbGludXgtYXNwZWVkLzIwMjMtRmVicnVhcnkvMDA5ODkyLmh0 bWwKWzNdOiBodHRwczovL2xpc3RzLm96bGFicy5vcmcvcGlwZXJtYWlsL2xpbnV4LWFzcGVlZC8y MDIzLUZlYnJ1YXJ5LzAwOTg4MC5odG1sCls0XTogaHR0cHM6Ly9saXN0cy5vemxhYnMub3JnL3Bp cGVybWFpbC9saW51eC1hc3BlZWQvMjAyMy1GZWJydWFyeS8wMDk4NzEuaHRtbApbNV06IGh0dHBz Oi8vbGlzdHMub3psYWJzLm9yZy9waXBlcm1haWwvbGludXgtYXNwZWVkLzIwMjMtRmVicnVhcnkv MDA5ODg0Lmh0bWwKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fCmxpbnV4LWFybS1rZXJuZWwgbWFpbGluZyBsaXN0CmxpbnV4LWFybS1rZXJuZWxAbGlzdHMu aW5mcmFkZWFkLm9yZwpodHRwOi8vbGlzdHMuaW5mcmFkZWFkLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2xpbnV4LWFybS1rZXJuZWwK