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 04CDBEB64D7 for ; Fri, 23 Jun 2023 16:46:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232135AbjFWQp5 (ORCPT ); Fri, 23 Jun 2023 12:45:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53720 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231732AbjFWQpx (ORCPT ); Fri, 23 Jun 2023 12:45:53 -0400 Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D8DED2941; Fri, 23 Jun 2023 09:45:49 -0700 (PDT) Received: from pps.filterd (m0353729.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 35NGb2OW021505; Fri, 23 Jun 2023 16:45:23 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : date : mime-version : subject : to : cc : references : from : in-reply-to : content-type : content-transfer-encoding; s=pp1; bh=I8SWemhR+QCoNTe129luI4bSps2rAXe9z6RPAhhT/B0=; b=sDJeKgtyxzShgDBYJ6THoB01wXVRHLtw95uyHDEc/3MwHRtuM/DZo/uVsaGjyLjly151 bIW8ctPJQcyNqJM1OnmZtArPr5cTuKFUCS4ubFiE0110+DHJwI0qVmp2QDS6s1h5Jgf3 Hn36cNXCry6UqMuASwu23vqP2H5pLb1hahR+dmrscInr4M4jUZiFVffE2hIuI3nQSiNs kumtMygMOXUVsr621JqjjzeetcebNGI8cmLgGYaEbnyDir4m6ckJPR3pbZCHbPfe9tbJ htPkSBsyQHujAH8y4gdwY6pUhGQhapJc9jZKVwXO1misALIbPJPNCx0Ar93ezGYEZw/e Hw== Received: from ppma03wdc.us.ibm.com (ba.79.3fa9.ip4.static.sl-reverse.com [169.63.121.186]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3rdesarewx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 23 Jun 2023 16:45:22 +0000 Received: from pps.filterd (ppma03wdc.us.ibm.com [127.0.0.1]) by ppma03wdc.us.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 35NFE3AW016016; Fri, 23 Jun 2023 16:45:21 GMT Received: from smtprelay05.wdc07v.mail.ibm.com ([9.208.129.117]) by ppma03wdc.us.ibm.com (PPS) with ESMTPS id 3r94f6fuh8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 23 Jun 2023 16:45:21 +0000 Received: from smtpav01.wdc07v.mail.ibm.com (smtpav01.wdc07v.mail.ibm.com [10.39.53.228]) by smtprelay05.wdc07v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 35NGjKvU5767738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 23 Jun 2023 16:45:20 GMT Received: from smtpav01.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 0633258059; Fri, 23 Jun 2023 16:45:20 +0000 (GMT) Received: from smtpav01.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 63D405804B; Fri, 23 Jun 2023 16:45:19 +0000 (GMT) Received: from [9.61.119.251] (unknown [9.61.119.251]) by smtpav01.wdc07v.mail.ibm.com (Postfix) with ESMTP; Fri, 23 Jun 2023 16:45:19 +0000 (GMT) Message-ID: <9cc6addc-cd41-7794-79a0-5c776946f492@linux.ibm.com> Date: Fri, 23 Jun 2023 11:45:19 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: [PATCH v2 3/4] spi: Split transfers larger than max size To: Mark Brown Cc: Vincent Whitchurch , krzysztof.kozlowski@linaro.org, andi@etezian.org, kernel@axis.com, alim.akhtar@samsung.com, linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org, linux-samsung-soc@vger.kernel.org, linux-arm-kernel@lists.infradead.org References: <20220927112117.77599-1-vincent.whitchurch@axis.com> <20220927112117.77599-4-vincent.whitchurch@axis.com> <6dff003d-c727-e4a3-b5d3-f58beb2b02cb@linux.ibm.com> Content-Language: en-US From: Eddie James In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: rpLJitQz5Z2uiSLhRQ6yHppBOusY_BTH X-Proofpoint-GUID: rpLJitQz5Z2uiSLhRQ6yHppBOusY_BTH X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.957,Hydra:6.0.591,FMLib:17.11.176.26 definitions=2023-06-23_08,2023-06-22_02,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 priorityscore=1501 bulkscore=0 suspectscore=0 phishscore=0 mlxlogscore=999 lowpriorityscore=0 adultscore=0 clxscore=1015 malwarescore=0 mlxscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2305260000 definitions=main-2306230148 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 6/22/23 16:16, Mark Brown wrote: > On Thu, Jun 22, 2023 at 02:48:36PM -0500, Eddie James wrote: >> On 9/27/22 06:21, Vincent Whitchurch wrote: >>> A couple of drivers call spi_split_transfers_maxsize() from their >>> ->prepare_message() callbacks to split transfers which are too big for >>> them to handle. Add support in the core to do this based on >>> ->max_transfer_size() to avoid code duplication. >> I've been testing AT25 functionality in linux 6.1 and I believe this patch >> is breaking the AT25 protocol. It will split a write command up such that >> some of the data is in a different transfer than  the write enable and >> address. According to my understanding of the AT25 spec, that doesn't >> work... Someone correct me if I'm wrong though. Do we need a flag to >> enable/disable this behavior depending on the client perhaps? > Could you be more specific about the manner in which you think this is > breaking things? The size of transfer is immaterial to the client > device on SPI, the client will be counting clocks while the chip select > is asserted. How the controller chooses to split things up is really > not particularly visible or relevant, it might bitbang things out one > bit at a time, transfer a single word at a time or batch things up > further. So long as the chip select is asserted it's all the same to > the client device. Ok, I understand better now. Agreed it shouldn't make a difference, but this is actually a limitation of the spi controller I'm using (spi-fsi). The controller cannot handle multiple transfers keeping the chip select enabled... I guess the driver can batch transfers in the message to get around this, unless you want to add a flag for that behavior. > > In any case this is all based on the maximum transfer size advertised by > the conteroller driver, if the device can physically handle larger > transfers then there's no reason for it to set a limit. If the driver > can't physically handle larger transfers and it does make a difference > then the system simply won't work. Yep, this is also an artifact of the spi-fsi driver having different transfer size limits for writes and reads. Funnily enough the at25 driver doesn't truly respect the max transfer size (it doesn't include the write command and address bytes in the calculation against the max transfer size) so that's how this worked previously. Thanks! Eddie 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 AE393EB64D7 for ; Fri, 23 Jun 2023 16:46:16 +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-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=bLFeUOU7qKZ4zELLBPZ7fbJsw7j8USJgynRX8md5PY4=; b=QxHRyP/kpStEg/ VYFoebr81iylBhKCF0+8NNqKhvfgifJuhTExbQmgv9FSsmxkXFqOvcE6EYQ0TN5q1BJi+5udBmcT9 e1HQZ/PIeHz8Hz1n1isOLQnWHYsmXy6rKYvkhwezqiEIPql+MCTlsIjuuTgkpIKJXwianSPNY2pnO cLfpBKdp4uxAdKn6WfEW6PDC8D+cB9HSZF03kfGAHTFjoQSgTqdvl+xMyT3bi5rYr/7/ZOq6WmLzD 4doGzdSrfBdSamGbD7KiKhRwmEiUniEaKNaL3sVV0QZ30dgDjBbX7v2mSVOyyoCdTJYLeEfrjtqF+ TbN881/h96rmQvDgbtBA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qCjuu-00479f-2m; Fri, 23 Jun 2023 16:45:48 +0000 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qCjus-00478t-05 for linux-arm-kernel@lists.infradead.org; Fri, 23 Jun 2023 16:45:47 +0000 Received: from pps.filterd (m0353729.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 35NGb2OW021505; Fri, 23 Jun 2023 16:45:23 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : date : mime-version : subject : to : cc : references : from : in-reply-to : content-type : content-transfer-encoding; s=pp1; bh=I8SWemhR+QCoNTe129luI4bSps2rAXe9z6RPAhhT/B0=; b=sDJeKgtyxzShgDBYJ6THoB01wXVRHLtw95uyHDEc/3MwHRtuM/DZo/uVsaGjyLjly151 bIW8ctPJQcyNqJM1OnmZtArPr5cTuKFUCS4ubFiE0110+DHJwI0qVmp2QDS6s1h5Jgf3 Hn36cNXCry6UqMuASwu23vqP2H5pLb1hahR+dmrscInr4M4jUZiFVffE2hIuI3nQSiNs kumtMygMOXUVsr621JqjjzeetcebNGI8cmLgGYaEbnyDir4m6ckJPR3pbZCHbPfe9tbJ htPkSBsyQHujAH8y4gdwY6pUhGQhapJc9jZKVwXO1misALIbPJPNCx0Ar93ezGYEZw/e Hw== Received: from ppma03wdc.us.ibm.com (ba.79.3fa9.ip4.static.sl-reverse.com [169.63.121.186]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3rdesarewx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 23 Jun 2023 16:45:22 +0000 Received: from pps.filterd (ppma03wdc.us.ibm.com [127.0.0.1]) by ppma03wdc.us.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 35NFE3AW016016; Fri, 23 Jun 2023 16:45:21 GMT Received: from smtprelay05.wdc07v.mail.ibm.com ([9.208.129.117]) by ppma03wdc.us.ibm.com (PPS) with ESMTPS id 3r94f6fuh8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 23 Jun 2023 16:45:21 +0000 Received: from smtpav01.wdc07v.mail.ibm.com (smtpav01.wdc07v.mail.ibm.com [10.39.53.228]) by smtprelay05.wdc07v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 35NGjKvU5767738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 23 Jun 2023 16:45:20 GMT Received: from smtpav01.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 0633258059; Fri, 23 Jun 2023 16:45:20 +0000 (GMT) Received: from smtpav01.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 63D405804B; Fri, 23 Jun 2023 16:45:19 +0000 (GMT) Received: from [9.61.119.251] (unknown [9.61.119.251]) by smtpav01.wdc07v.mail.ibm.com (Postfix) with ESMTP; Fri, 23 Jun 2023 16:45:19 +0000 (GMT) Message-ID: <9cc6addc-cd41-7794-79a0-5c776946f492@linux.ibm.com> Date: Fri, 23 Jun 2023 11:45:19 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: [PATCH v2 3/4] spi: Split transfers larger than max size To: Mark Brown Cc: Vincent Whitchurch , krzysztof.kozlowski@linaro.org, andi@etezian.org, kernel@axis.com, alim.akhtar@samsung.com, linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org, linux-samsung-soc@vger.kernel.org, linux-arm-kernel@lists.infradead.org References: <20220927112117.77599-1-vincent.whitchurch@axis.com> <20220927112117.77599-4-vincent.whitchurch@axis.com> <6dff003d-c727-e4a3-b5d3-f58beb2b02cb@linux.ibm.com> Content-Language: en-US From: Eddie James In-Reply-To: X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: rpLJitQz5Z2uiSLhRQ6yHppBOusY_BTH X-Proofpoint-GUID: rpLJitQz5Z2uiSLhRQ6yHppBOusY_BTH X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.957,Hydra:6.0.591,FMLib:17.11.176.26 definitions=2023-06-23_08,2023-06-22_02,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 priorityscore=1501 bulkscore=0 suspectscore=0 phishscore=0 mlxlogscore=999 lowpriorityscore=0 adultscore=0 clxscore=1015 malwarescore=0 mlxscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2305260000 definitions=main-2306230148 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230623_094546_286998_A43D5583 X-CRM114-Status: GOOD ( 29.39 ) 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-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Ck9uIDYvMjIvMjMgMTY6MTYsIE1hcmsgQnJvd24gd3JvdGU6Cj4gT24gVGh1LCBKdW4gMjIsIDIw MjMgYXQgMDI6NDg6MzZQTSAtMDUwMCwgRWRkaWUgSmFtZXMgd3JvdGU6Cj4+IE9uIDkvMjcvMjIg MDY6MjEsIFZpbmNlbnQgV2hpdGNodXJjaCB3cm90ZToKPj4+IEEgY291cGxlIG9mIGRyaXZlcnMg Y2FsbCBzcGlfc3BsaXRfdHJhbnNmZXJzX21heHNpemUoKSBmcm9tIHRoZWlyCj4+PiAtPnByZXBh cmVfbWVzc2FnZSgpIGNhbGxiYWNrcyB0byBzcGxpdCB0cmFuc2ZlcnMgd2hpY2ggYXJlIHRvbyBi aWcgZm9yCj4+PiB0aGVtIHRvIGhhbmRsZS4gIEFkZCBzdXBwb3J0IGluIHRoZSBjb3JlIHRvIGRv IHRoaXMgYmFzZWQgb24KPj4+IC0+bWF4X3RyYW5zZmVyX3NpemUoKSB0byBhdm9pZCBjb2RlIGR1 cGxpY2F0aW9uLgo+PiBJJ3ZlIGJlZW4gdGVzdGluZyBBVDI1IGZ1bmN0aW9uYWxpdHkgaW4gbGlu dXggNi4xIGFuZCBJIGJlbGlldmUgdGhpcyBwYXRjaAo+PiBpcyBicmVha2luZyB0aGUgQVQyNSBw cm90b2NvbC4gSXQgd2lsbCBzcGxpdCBhIHdyaXRlIGNvbW1hbmQgdXAgc3VjaCB0aGF0Cj4+IHNv bWUgb2YgdGhlIGRhdGEgaXMgaW4gYSBkaWZmZXJlbnQgdHJhbnNmZXIgdGhhbsKgIHRoZSB3cml0 ZSBlbmFibGUgYW5kCj4+IGFkZHJlc3MuIEFjY29yZGluZyB0byBteSB1bmRlcnN0YW5kaW5nIG9m IHRoZSBBVDI1IHNwZWMsIHRoYXQgZG9lc24ndAo+PiB3b3JrLi4uIFNvbWVvbmUgY29ycmVjdCBt ZSBpZiBJJ20gd3JvbmcgdGhvdWdoLiBEbyB3ZSBuZWVkIGEgZmxhZyB0bwo+PiBlbmFibGUvZGlz YWJsZSB0aGlzIGJlaGF2aW9yIGRlcGVuZGluZyBvbiB0aGUgY2xpZW50IHBlcmhhcHM/Cj4gQ291 bGQgeW91IGJlIG1vcmUgc3BlY2lmaWMgYWJvdXQgdGhlIG1hbm5lciBpbiB3aGljaCB5b3UgdGhp bmsgdGhpcyBpcwo+IGJyZWFraW5nIHRoaW5ncz8gIFRoZSBzaXplIG9mIHRyYW5zZmVyIGlzIGlt bWF0ZXJpYWwgdG8gdGhlIGNsaWVudAo+IGRldmljZSBvbiBTUEksIHRoZSBjbGllbnQgd2lsbCBi ZSBjb3VudGluZyBjbG9ja3Mgd2hpbGUgdGhlIGNoaXAgc2VsZWN0Cj4gaXMgYXNzZXJ0ZWQuICBI b3cgdGhlIGNvbnRyb2xsZXIgY2hvb3NlcyB0byBzcGxpdCB0aGluZ3MgdXAgaXMgcmVhbGx5Cj4g bm90IHBhcnRpY3VsYXJseSB2aXNpYmxlIG9yIHJlbGV2YW50LCBpdCBtaWdodCBiaXRiYW5nIHRo aW5ncyBvdXQgb25lCj4gYml0IGF0IGEgdGltZSwgdHJhbnNmZXIgYSBzaW5nbGUgd29yZCBhdCBh IHRpbWUgb3IgYmF0Y2ggdGhpbmdzIHVwCj4gZnVydGhlci4gIFNvIGxvbmcgYXMgdGhlIGNoaXAg c2VsZWN0IGlzIGFzc2VydGVkIGl0J3MgYWxsIHRoZSBzYW1lIHRvCj4gdGhlIGNsaWVudCBkZXZp Y2UuCgoKT2ssIEkgdW5kZXJzdGFuZCBiZXR0ZXIgbm93LiBBZ3JlZWQgaXQgc2hvdWxkbid0IG1h a2UgYSBkaWZmZXJlbmNlLCBidXQgCnRoaXMgaXMgYWN0dWFsbHkgYSBsaW1pdGF0aW9uIG9mIHRo ZSBzcGkgY29udHJvbGxlciBJJ20gdXNpbmcgKHNwaS1mc2kpLiAKVGhlIGNvbnRyb2xsZXIgY2Fu bm90IGhhbmRsZSBtdWx0aXBsZSB0cmFuc2ZlcnMga2VlcGluZyB0aGUgY2hpcCBzZWxlY3QgCmVu YWJsZWQuLi4gSSBndWVzcyB0aGUgZHJpdmVyIGNhbiBiYXRjaCB0cmFuc2ZlcnMgaW4gdGhlIG1l c3NhZ2UgdG8gZ2V0IAphcm91bmQgdGhpcywgdW5sZXNzIHlvdSB3YW50IHRvIGFkZCBhIGZsYWcg Zm9yIHRoYXQgYmVoYXZpb3IuCgoKPgo+IEluIGFueSBjYXNlIHRoaXMgaXMgYWxsIGJhc2VkIG9u IHRoZSBtYXhpbXVtIHRyYW5zZmVyIHNpemUgYWR2ZXJ0aXNlZCBieQo+IHRoZSBjb250ZXJvbGxl ciBkcml2ZXIsIGlmIHRoZSBkZXZpY2UgY2FuIHBoeXNpY2FsbHkgaGFuZGxlIGxhcmdlcgo+IHRy YW5zZmVycyB0aGVuIHRoZXJlJ3Mgbm8gcmVhc29uIGZvciBpdCB0byBzZXQgYSBsaW1pdC4gIElm IHRoZSBkcml2ZXIKPiBjYW4ndCBwaHlzaWNhbGx5IGhhbmRsZSBsYXJnZXIgdHJhbnNmZXJzIGFu ZCBpdCBkb2VzIG1ha2UgYSBkaWZmZXJlbmNlCj4gdGhlbiB0aGUgc3lzdGVtIHNpbXBseSB3b24n dCB3b3JrLgoKClllcCwgdGhpcyBpcyBhbHNvIGFuIGFydGlmYWN0IG9mIHRoZSBzcGktZnNpIGRy aXZlciBoYXZpbmcgZGlmZmVyZW50IAp0cmFuc2ZlciBzaXplIGxpbWl0cyBmb3Igd3JpdGVzIGFu ZCByZWFkcy4gRnVubmlseSBlbm91Z2ggdGhlIGF0MjUgCmRyaXZlciBkb2Vzbid0IHRydWx5IHJl c3BlY3QgdGhlIG1heCB0cmFuc2ZlciBzaXplIChpdCBkb2Vzbid0IGluY2x1ZGUgCnRoZSB3cml0 ZSBjb21tYW5kIGFuZCBhZGRyZXNzIGJ5dGVzIGluIHRoZSBjYWxjdWxhdGlvbiBhZ2FpbnN0IHRo ZSBtYXggCnRyYW5zZmVyIHNpemUpIHNvIHRoYXQncyBob3cgdGhpcyB3b3JrZWQgcHJldmlvdXNs eS4KClRoYW5rcyEKCkVkZGllCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fCmxpbnV4LWFybS1rZXJuZWwgbWFpbGluZyBsaXN0CmxpbnV4LWFybS1rZXJu ZWxAbGlzdHMuaW5mcmFkZWFkLm9yZwpodHRwOi8vbGlzdHMuaW5mcmFkZWFkLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2xpbnV4LWFybS1rZXJuZWwK