From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtpout-03.galae.net (smtpout-03.galae.net [185.246.85.4]) (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 117403B27FB for ; Wed, 1 Apr 2026 08:32:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.246.85.4 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775032341; cv=none; b=i7PfSC8bS7ZNvJhXxD76ZeXLJVQyMZTLOcbB7KkudcJTechVQylo1zvH/emK3KJDNQJVGb+RL4BaT07OzKzqm5PAnFC5RBC4fk7N7t7J4FSgzXmnqc40XghPcVNIUkLuZByp5pbJa+eSvQX4sAE3ec8A6ufc2jRWVwEWGxvot2I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775032341; c=relaxed/simple; bh=Fs+CGKEUt1ElyhYrbunyFdQOzG2qbZr8EbkvS0lQATM=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=BJozyY3KhDWcxqsdERGd3Q2lzji+JXMA1/hKaT2H4X8cYkU1x5mDXE2QZvI0if9SJan46pGfXlQl+3Vl0z4yUpeAN67O2Z4yEXEJAKl1RsW6iE7iH0q5f5WSn8aoCcdfsv/e0xsggf2kGHp6oqDHBdetysy3zQhGLu6radLCLwQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com; spf=pass smtp.mailfrom=bootlin.com; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b=fto/JPni; arc=none smtp.client-ip=185.246.85.4 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bootlin.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b="fto/JPni" Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-03.galae.net (Postfix) with ESMTPS id 437AF4E42894; Wed, 1 Apr 2026 08:32:17 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id EFBFE602BF; Wed, 1 Apr 2026 08:32:16 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id CB770104509A9; Wed, 1 Apr 2026 10:32:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1775032335; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=Fs+CGKEUt1ElyhYrbunyFdQOzG2qbZr8EbkvS0lQATM=; b=fto/JPni0c1YOWLjhCWBPwqKHiMHbfSQuQEZso7ZVx5iqbGyZTPkZ5CKJEX1lZJ4RF8Ykf lFZrD8Qr4iUeDG6X0XA2zSiyg0eHQvz2m0+9RUsBINHftygBnlNTTAbENLTJ51vPCnKbih +Fr/r7xOpcxaCBMBMtdy2txzIuN7mJjtxjWkU7+VqVrbqBnh5dKB3UUKoMOaKHzDrIiko5 0ZAsfmCt9JCUykyIye1ju+n8N+OXfDqNBsWqNiHwbpJEAqFhY9iWlf93fP831/Ucq/65FZ 6DjOSq5kGFuzkUyt3zZc/hGhfU7OKl4dsHFOdZzTF0nDUFyMDS56DOKv3c12IQ== From: Miquel Raynal To: Frieder Schrempf Cc: Frieder Schrempf , Mark Brown , Richard Weinberger , Vignesh Raghavendra , Han Xu , Eberhard Stoll , Tudor Ambarus , Pratyush Yadav , Michael Walle , linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org, imx@lists.linux.dev, Santhosh Kumar K Subject: Re: [PATCH RFC 6/7] spi: spi-mem: Call spi_set_rx_sampling_point() for each op In-Reply-To: (Frieder Schrempf's message of "Tue, 31 Mar 2026 19:57:21 +0200") References: <20260303-fsl-qspi-rx-sampling-delay-v1-0-9326bbc492d6@kontron.de> <20260303-fsl-qspi-rx-sampling-delay-v1-6-9326bbc492d6@kontron.de> <87wlzlnioh.fsf@bootlin.com> <87ecl09wtv.fsf@bootlin.com> <633fee13-a397-410f-a595-db95e04b8110@kontron.de> <87ldf881gr.fsf@bootlin.com> User-Agent: mu4e 1.12.7; emacs 30.2 Date: Wed, 01 Apr 2026 10:32:11 +0200 Message-ID: <874ilv84j8.fsf@bootlin.com> Precedence: bulk X-Mailing-List: imx@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Last-TLS-Session-Version: TLSv1.3 Hi Frieder, > The RX delay introduced by the chip is not design-dependent, only > chip-dependent. There might be additional delays introduced by the board > layout, but that's out of scope currently and I don't know if we even > need this. We do, for very high speeds, and this is the purpose of the PHY tuning series from Santhosh. [...] >>> 3. By default limit the clock frequency for the READ_ID op to a safe >>> value that works for all chips and controllers, even if RX sampling >>> delay compensations is not available. >>=20 >> I am sorry this is not going to work out. There is no such harmonized >> speed, differences can be an order (or two) of magnitude different, we >> do not want to pay the penalty of a very slow identification on all >> designs. We currently do the read several times with different >> parameters. What if we were trying one more time by cutting the speed by >> 2 (completely random proposal)? > > If we try with reduced clock as a fallback after the other attempts, > there would be a slight chance of one of the earlier attempts with > normal clock rate returning some invalid data that matches an existing > chip ID, no? Isn't this a bit flaky? Yeah, I understand your (and Mark's) concern. > Let's say for a worst case scenario a chip has an RX delay of 20ns (the > highest I've seen in datasheets so far is 8ns). In that case the maximum > clock we could safely use for reading the ID would be 1/(2*20e-9) =3D > 25MHz. Do you think it really makes much of a difference if we read the > ID (only a handful of bytes) at 25MHz or full speed (e. g. 104 MHz)? I > mean this should be fast enough either way, no? But maybe I'm misjudging > this. I am honestly not a big fan of the global penalty, but I am not totally opposed either, especially since you just said you only observed 8ns delays at most. This is 62.5MHz, which is already above what most designs use, so the penalty would be minimal. What about taking this approach and see if that fixes most of our use cases? >>> 4. In PHY mode, check against the DT max frequency (board limitations) >>> and chip max frequency before switching to this mode. >>=20 >> There is not such thing :-) the max frequency in DT currently would be >> set to the platform limitation. We need somehow another parameter >> indicating what is the maximum speed if we can fine tune the timings. > > So we can exceed the platform limitations using fine-tuned timings? I > guess I need to read and understand that tuning RFC series. Well, this is still under discussion. As of today, the max speed in DT is the maximum speed. But it is in most cases the maximum speed *without* tuning, which means if we tune the PHY delays we can increase the speed further. I already proposed to turn this DT property into an array, in order to indicate what are the maximum speed*s*, without and with tuning, if ever possible. >>> I hope this makes at least a bit of sense. I'm really not yet familiar >>> with all the different use-cases and limitations. >>=20 >> If I get back to your own issue. Is there any chance we could avoid >> tweaking the DT for handling it? Would there be a configuration of your >> controller that would allow reading the ID of all the chips with enough >> delays? Currently, the spi core doesn't care much about other parameters >> than the frequency, but there is perhaps room for improvement. > > We could use RX delay compensation (one half clock cycle) in the > controller by default (as currently done by the STM32 driver). But that > would break if we use a very low clock (for whatever reason) because > then the RX sampling delay gets neglectable compared to the clock period > and sampling is triggered at the very end of the clock cycle when the > data might already be invalid. At least that's what I suspect based on > my test results. > And it would also break if the chip actually requires more than one half > clock cycle of RX sampling delay. > > The RX sampling delay setting must match the used clock frequency. In > most cases there is a lot of room for tolerance before things start to > fail, but it's not endless and especially at very high clock rates we > need to take it into account. > > So if we don't cap the speed for reading the ID by default, we somehow > need to know what value to use for the RX sampling delay or we need to > try different values. And if the controller does not support or > implement the RX sampling delay compensation, we need to cap the speed > anyway. What about: *SPI controller drivers* - Enable RX delay compensation in the controller by default, disable it if the speed is very low, ie. compensation is dangerous *Core* - READID at max 65MHz (with the default RX delay compensation) *Vendor driver* - Indicate the internal RX delay per chip (maybe we need some heuristics depending on the speed as well?) *SPI controller drivers* - Hook to tune RX based on the fastest reachable speed. Thanks, Miqu=C3=A8l 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 E594BD35159 for ; Wed, 1 Apr 2026 08:32:32 +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:Message-ID:Date:References :In-Reply-To:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=F4/JmRXrkvNhaU04Zm/1WZ//6YPY3HytVog2Tf6rwjM=; b=pTPKl8S+wscROn 7aTTlmQkStKdTwvardpNb2pJLXJQjXGwO4VuMb/PCEsL77cBGPEtn1FPvoB/2DHbbUAqMXUqeNvZe oGyFEImBvmLgvW98/6Y6AyFDx+DxZzWKdyhDzQWlp7rY2MSjYMWshEKWi4LeRACKn/8ClZAkiVuej TiXiS0VkJxM4Ce2ZHO7MPbhXO5e4hLZ3+gnDqsNi/bwxFIYbdMOPDUqkIO0KwjwoW3yLwuZ6r4Vh0 e5dmw+8255oKau8fwrwPKTiLpA86R1KkKHq7fw9f6jDxH/I69g7vWtr4lIwPQbOt7ZU8n3AN7x6DT ajW4mUyYrZCDwDz7zZPA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1w7qzx-0000000EKAV-0oWL; Wed, 01 Apr 2026 08:32:25 +0000 Received: from smtpout-03.galae.net ([185.246.85.4]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1w7qzs-0000000EK9t-3606 for linux-mtd@lists.infradead.org; Wed, 01 Apr 2026 08:32:22 +0000 Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-03.galae.net (Postfix) with ESMTPS id 437AF4E42894; Wed, 1 Apr 2026 08:32:17 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id EFBFE602BF; Wed, 1 Apr 2026 08:32:16 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id CB770104509A9; Wed, 1 Apr 2026 10:32:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1775032335; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=Fs+CGKEUt1ElyhYrbunyFdQOzG2qbZr8EbkvS0lQATM=; b=fto/JPni0c1YOWLjhCWBPwqKHiMHbfSQuQEZso7ZVx5iqbGyZTPkZ5CKJEX1lZJ4RF8Ykf lFZrD8Qr4iUeDG6X0XA2zSiyg0eHQvz2m0+9RUsBINHftygBnlNTTAbENLTJ51vPCnKbih +Fr/r7xOpcxaCBMBMtdy2txzIuN7mJjtxjWkU7+VqVrbqBnh5dKB3UUKoMOaKHzDrIiko5 0ZAsfmCt9JCUykyIye1ju+n8N+OXfDqNBsWqNiHwbpJEAqFhY9iWlf93fP831/Ucq/65FZ 6DjOSq5kGFuzkUyt3zZc/hGhfU7OKl4dsHFOdZzTF0nDUFyMDS56DOKv3c12IQ== From: Miquel Raynal To: Frieder Schrempf Cc: Frieder Schrempf , Mark Brown , Richard Weinberger , Vignesh Raghavendra , Han Xu , Eberhard Stoll , Tudor Ambarus , Pratyush Yadav , Michael Walle , linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org, imx@lists.linux.dev, Santhosh Kumar K Subject: Re: [PATCH RFC 6/7] spi: spi-mem: Call spi_set_rx_sampling_point() for each op In-Reply-To: (Frieder Schrempf's message of "Tue, 31 Mar 2026 19:57:21 +0200") References: <20260303-fsl-qspi-rx-sampling-delay-v1-0-9326bbc492d6@kontron.de> <20260303-fsl-qspi-rx-sampling-delay-v1-6-9326bbc492d6@kontron.de> <87wlzlnioh.fsf@bootlin.com> <87ecl09wtv.fsf@bootlin.com> <633fee13-a397-410f-a595-db95e04b8110@kontron.de> <87ldf881gr.fsf@bootlin.com> User-Agent: mu4e 1.12.7; emacs 30.2 Date: Wed, 01 Apr 2026 10:32:11 +0200 Message-ID: <874ilv84j8.fsf@bootlin.com> MIME-Version: 1.0 X-Last-TLS-Session-Version: TLSv1.3 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260401_013221_044835_4F0E592B X-CRM114-Status: GOOD ( 34.63 ) X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-mtd" Errors-To: linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org SGkgRnJpZWRlciwKCj4gVGhlIFJYIGRlbGF5IGludHJvZHVjZWQgYnkgdGhlIGNoaXAgaXMgbm90 IGRlc2lnbi1kZXBlbmRlbnQsIG9ubHkKPiBjaGlwLWRlcGVuZGVudC4gVGhlcmUgbWlnaHQgYmUg YWRkaXRpb25hbCBkZWxheXMgaW50cm9kdWNlZCBieSB0aGUgYm9hcmQKPiBsYXlvdXQsIGJ1dCB0 aGF0J3Mgb3V0IG9mIHNjb3BlIGN1cnJlbnRseSBhbmQgSSBkb24ndCBrbm93IGlmIHdlIGV2ZW4K PiBuZWVkIHRoaXMuCgpXZSBkbywgZm9yIHZlcnkgaGlnaCBzcGVlZHMsIGFuZCB0aGlzIGlzIHRo ZSBwdXJwb3NlIG9mIHRoZSBQSFkgdHVuaW5nCnNlcmllcyBmcm9tIFNhbnRob3NoLgoKWy4uLl0K Cj4+PiAzLiBCeSBkZWZhdWx0IGxpbWl0IHRoZSBjbG9jayBmcmVxdWVuY3kgZm9yIHRoZSBSRUFE X0lEIG9wIHRvIGEgc2FmZQo+Pj4gdmFsdWUgdGhhdCB3b3JrcyBmb3IgYWxsIGNoaXBzIGFuZCBj b250cm9sbGVycywgZXZlbiBpZiBSWCBzYW1wbGluZwo+Pj4gZGVsYXkgY29tcGVuc2F0aW9ucyBp cyBub3QgYXZhaWxhYmxlLgo+PiAKPj4gSSBhbSBzb3JyeSB0aGlzIGlzIG5vdCBnb2luZyB0byB3 b3JrIG91dC4gVGhlcmUgaXMgbm8gc3VjaCBoYXJtb25pemVkCj4+IHNwZWVkLCBkaWZmZXJlbmNl cyBjYW4gYmUgYW4gb3JkZXIgKG9yIHR3bykgb2YgbWFnbml0dWRlIGRpZmZlcmVudCwgd2UKPj4g ZG8gbm90IHdhbnQgdG8gcGF5IHRoZSBwZW5hbHR5IG9mIGEgdmVyeSBzbG93IGlkZW50aWZpY2F0 aW9uIG9uIGFsbAo+PiBkZXNpZ25zLiBXZSBjdXJyZW50bHkgZG8gdGhlIHJlYWQgc2V2ZXJhbCB0 aW1lcyB3aXRoIGRpZmZlcmVudAo+PiBwYXJhbWV0ZXJzLiBXaGF0IGlmIHdlIHdlcmUgdHJ5aW5n IG9uZSBtb3JlIHRpbWUgYnkgY3V0dGluZyB0aGUgc3BlZWQgYnkKPj4gMiAoY29tcGxldGVseSBy YW5kb20gcHJvcG9zYWwpPwo+Cj4gSWYgd2UgdHJ5IHdpdGggcmVkdWNlZCBjbG9jayBhcyBhIGZh bGxiYWNrIGFmdGVyIHRoZSBvdGhlciBhdHRlbXB0cywKPiB0aGVyZSB3b3VsZCBiZSBhIHNsaWdo dCBjaGFuY2Ugb2Ygb25lIG9mIHRoZSBlYXJsaWVyIGF0dGVtcHRzIHdpdGgKPiBub3JtYWwgY2xv Y2sgcmF0ZSByZXR1cm5pbmcgc29tZSBpbnZhbGlkIGRhdGEgdGhhdCBtYXRjaGVzIGFuIGV4aXN0 aW5nCj4gY2hpcCBJRCwgbm8/IElzbid0IHRoaXMgYSBiaXQgZmxha3k/CgpZZWFoLCBJIHVuZGVy c3RhbmQgeW91ciAoYW5kIE1hcmsncykgY29uY2Vybi4KCj4gTGV0J3Mgc2F5IGZvciBhIHdvcnN0 IGNhc2Ugc2NlbmFyaW8gYSBjaGlwIGhhcyBhbiBSWCBkZWxheSBvZiAyMG5zICh0aGUKPiBoaWdo ZXN0IEkndmUgc2VlbiBpbiBkYXRhc2hlZXRzIHNvIGZhciBpcyA4bnMpLiBJbiB0aGF0IGNhc2Ug dGhlIG1heGltdW0KPiBjbG9jayB3ZSBjb3VsZCBzYWZlbHkgdXNlIGZvciByZWFkaW5nIHRoZSBJ RCB3b3VsZCBiZSAxLygyKjIwZS05KSA9Cj4gMjVNSHouIERvIHlvdSB0aGluayBpdCByZWFsbHkg bWFrZXMgbXVjaCBvZiBhIGRpZmZlcmVuY2UgaWYgd2UgcmVhZCB0aGUKPiBJRCAob25seSBhIGhh bmRmdWwgb2YgYnl0ZXMpIGF0IDI1TUh6IG9yIGZ1bGwgc3BlZWQgKGUuIGcuIDEwNCBNSHopPyBJ Cj4gbWVhbiB0aGlzIHNob3VsZCBiZSBmYXN0IGVub3VnaCBlaXRoZXIgd2F5LCBubz8gQnV0IG1h eWJlIEknbSBtaXNqdWRnaW5nCj4gdGhpcy4KCkkgYW0gaG9uZXN0bHkgbm90IGEgYmlnIGZhbiBv ZiB0aGUgZ2xvYmFsIHBlbmFsdHksIGJ1dCBJIGFtIG5vdCB0b3RhbGx5Cm9wcG9zZWQgZWl0aGVy LCBlc3BlY2lhbGx5IHNpbmNlIHlvdSBqdXN0IHNhaWQgeW91IG9ubHkgb2JzZXJ2ZWQgOG5zCmRl bGF5cyBhdCBtb3N0LiBUaGlzIGlzIDYyLjVNSHosIHdoaWNoIGlzIGFscmVhZHkgYWJvdmUgd2hh dCBtb3N0CmRlc2lnbnMgdXNlLCBzbyB0aGUgcGVuYWx0eSB3b3VsZCBiZSBtaW5pbWFsLiBXaGF0 IGFib3V0IHRha2luZyB0aGlzCmFwcHJvYWNoIGFuZCBzZWUgaWYgdGhhdCBmaXhlcyBtb3N0IG9m IG91ciB1c2UgY2FzZXM/Cgo+Pj4gNC4gSW4gUEhZIG1vZGUsIGNoZWNrIGFnYWluc3QgdGhlIERU IG1heCBmcmVxdWVuY3kgKGJvYXJkIGxpbWl0YXRpb25zKQo+Pj4gYW5kIGNoaXAgbWF4IGZyZXF1 ZW5jeSBiZWZvcmUgc3dpdGNoaW5nIHRvIHRoaXMgbW9kZS4KPj4gCj4+IFRoZXJlIGlzIG5vdCBz dWNoIHRoaW5nIDotKSB0aGUgbWF4IGZyZXF1ZW5jeSBpbiBEVCBjdXJyZW50bHkgd291bGQgYmUK Pj4gc2V0IHRvIHRoZSBwbGF0Zm9ybSBsaW1pdGF0aW9uLiBXZSBuZWVkIHNvbWVob3cgYW5vdGhl ciBwYXJhbWV0ZXIKPj4gaW5kaWNhdGluZyB3aGF0IGlzIHRoZSBtYXhpbXVtIHNwZWVkIGlmIHdl IGNhbiBmaW5lIHR1bmUgdGhlIHRpbWluZ3MuCj4KPiBTbyB3ZSBjYW4gZXhjZWVkIHRoZSBwbGF0 Zm9ybSBsaW1pdGF0aW9ucyB1c2luZyBmaW5lLXR1bmVkIHRpbWluZ3M/IEkKPiBndWVzcyBJIG5l ZWQgdG8gcmVhZCBhbmQgdW5kZXJzdGFuZCB0aGF0IHR1bmluZyBSRkMgc2VyaWVzLgoKV2VsbCwg dGhpcyBpcyBzdGlsbCB1bmRlciBkaXNjdXNzaW9uLiBBcyBvZiB0b2RheSwgdGhlIG1heCBzcGVl ZCBpbiBEVAppcyB0aGUgbWF4aW11bSBzcGVlZC4gQnV0IGl0IGlzIGluIG1vc3QgY2FzZXMgdGhl IG1heGltdW0gc3BlZWQKKndpdGhvdXQqIHR1bmluZywgd2hpY2ggbWVhbnMgaWYgd2UgdHVuZSB0 aGUgUEhZIGRlbGF5cyB3ZSBjYW4gaW5jcmVhc2UKdGhlIHNwZWVkIGZ1cnRoZXIuIEkgYWxyZWFk eSBwcm9wb3NlZCB0byB0dXJuIHRoaXMgRFQgcHJvcGVydHkgaW50byBhbgphcnJheSwgaW4gb3Jk ZXIgdG8gaW5kaWNhdGUgd2hhdCBhcmUgdGhlIG1heGltdW0gc3BlZWQqcyosIHdpdGhvdXQgYW5k CndpdGggdHVuaW5nLCBpZiBldmVyIHBvc3NpYmxlLgoKPj4+IEkgaG9wZSB0aGlzIG1ha2VzIGF0 IGxlYXN0IGEgYml0IG9mIHNlbnNlLiBJJ20gcmVhbGx5IG5vdCB5ZXQgZmFtaWxpYXIKPj4+IHdp dGggYWxsIHRoZSBkaWZmZXJlbnQgdXNlLWNhc2VzIGFuZCBsaW1pdGF0aW9ucy4KPj4gCj4+IElm IEkgZ2V0IGJhY2sgdG8geW91ciBvd24gaXNzdWUuIElzIHRoZXJlIGFueSBjaGFuY2Ugd2UgY291 bGQgYXZvaWQKPj4gdHdlYWtpbmcgdGhlIERUIGZvciBoYW5kbGluZyBpdD8gV291bGQgdGhlcmUg YmUgYSBjb25maWd1cmF0aW9uIG9mIHlvdXIKPj4gY29udHJvbGxlciB0aGF0IHdvdWxkIGFsbG93 IHJlYWRpbmcgdGhlIElEIG9mIGFsbCB0aGUgY2hpcHMgd2l0aCBlbm91Z2gKPj4gZGVsYXlzPyBD dXJyZW50bHksIHRoZSBzcGkgY29yZSBkb2Vzbid0IGNhcmUgbXVjaCBhYm91dCBvdGhlciBwYXJh bWV0ZXJzCj4+IHRoYW4gdGhlIGZyZXF1ZW5jeSwgYnV0IHRoZXJlIGlzIHBlcmhhcHMgcm9vbSBm b3IgaW1wcm92ZW1lbnQuCj4KPiBXZSBjb3VsZCB1c2UgUlggZGVsYXkgY29tcGVuc2F0aW9uIChv bmUgaGFsZiBjbG9jayBjeWNsZSkgaW4gdGhlCj4gY29udHJvbGxlciBieSBkZWZhdWx0IChhcyBj dXJyZW50bHkgZG9uZSBieSB0aGUgU1RNMzIgZHJpdmVyKS4gQnV0IHRoYXQKPiB3b3VsZCBicmVh ayBpZiB3ZSB1c2UgYSB2ZXJ5IGxvdyBjbG9jayAoZm9yIHdoYXRldmVyIHJlYXNvbikgYmVjYXVz ZQo+IHRoZW4gdGhlIFJYIHNhbXBsaW5nIGRlbGF5IGdldHMgbmVnbGVjdGFibGUgY29tcGFyZWQg dG8gdGhlIGNsb2NrIHBlcmlvZAo+IGFuZCBzYW1wbGluZyBpcyB0cmlnZ2VyZWQgYXQgdGhlIHZl cnkgZW5kIG9mIHRoZSBjbG9jayBjeWNsZSB3aGVuIHRoZQo+IGRhdGEgbWlnaHQgYWxyZWFkeSBi ZSBpbnZhbGlkLiBBdCBsZWFzdCB0aGF0J3Mgd2hhdCBJIHN1c3BlY3QgYmFzZWQgb24KPiBteSB0 ZXN0IHJlc3VsdHMuCj4gQW5kIGl0IHdvdWxkIGFsc28gYnJlYWsgaWYgdGhlIGNoaXAgYWN0dWFs bHkgcmVxdWlyZXMgbW9yZSB0aGFuIG9uZSBoYWxmCj4gY2xvY2sgY3ljbGUgb2YgUlggc2FtcGxp bmcgZGVsYXkuCj4KPiBUaGUgUlggc2FtcGxpbmcgZGVsYXkgc2V0dGluZyBtdXN0IG1hdGNoIHRo ZSB1c2VkIGNsb2NrIGZyZXF1ZW5jeS4gSW4KPiBtb3N0IGNhc2VzIHRoZXJlIGlzIGEgbG90IG9m IHJvb20gZm9yIHRvbGVyYW5jZSBiZWZvcmUgdGhpbmdzIHN0YXJ0IHRvCj4gZmFpbCwgYnV0IGl0 J3Mgbm90IGVuZGxlc3MgYW5kIGVzcGVjaWFsbHkgYXQgdmVyeSBoaWdoIGNsb2NrIHJhdGVzIHdl Cj4gbmVlZCB0byB0YWtlIGl0IGludG8gYWNjb3VudC4KPgo+IFNvIGlmIHdlIGRvbid0IGNhcCB0 aGUgc3BlZWQgZm9yIHJlYWRpbmcgdGhlIElEIGJ5IGRlZmF1bHQsIHdlIHNvbWVob3cKPiBuZWVk IHRvIGtub3cgd2hhdCB2YWx1ZSB0byB1c2UgZm9yIHRoZSBSWCBzYW1wbGluZyBkZWxheSBvciB3 ZSBuZWVkIHRvCj4gdHJ5IGRpZmZlcmVudCB2YWx1ZXMuIEFuZCBpZiB0aGUgY29udHJvbGxlciBk b2VzIG5vdCBzdXBwb3J0IG9yCj4gaW1wbGVtZW50IHRoZSBSWCBzYW1wbGluZyBkZWxheSBjb21w ZW5zYXRpb24sIHdlIG5lZWQgdG8gY2FwIHRoZSBzcGVlZAo+IGFueXdheS4KCldoYXQgYWJvdXQ6 CgoqU1BJIGNvbnRyb2xsZXIgZHJpdmVycyoKLSBFbmFibGUgUlggZGVsYXkgY29tcGVuc2F0aW9u IGluIHRoZSBjb250cm9sbGVyIGJ5IGRlZmF1bHQsIGRpc2FibGUgaXQKaWYgdGhlIHNwZWVkIGlz IHZlcnkgbG93LCBpZS4gY29tcGVuc2F0aW9uIGlzIGRhbmdlcm91cwoqQ29yZSoKLSBSRUFESUQg YXQgbWF4IDY1TUh6ICh3aXRoIHRoZSBkZWZhdWx0IFJYIGRlbGF5IGNvbXBlbnNhdGlvbikKKlZl bmRvciBkcml2ZXIqCi0gSW5kaWNhdGUgdGhlIGludGVybmFsIFJYIGRlbGF5IHBlciBjaGlwICht YXliZSB3ZSBuZWVkIHNvbWUgaGV1cmlzdGljcwpkZXBlbmRpbmcgb24gdGhlIHNwZWVkIGFzIHdl bGw/KQoqU1BJIGNvbnRyb2xsZXIgZHJpdmVycyoKLSBIb29rIHRvIHR1bmUgUlggYmFzZWQgb24g dGhlIGZhc3Rlc3QgcmVhY2hhYmxlIHNwZWVkLgoKVGhhbmtzLApNaXF1w6hsCgpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KTGludXggTVREIGRp c2N1c3Npb24gbWFpbGluZyBsaXN0Cmh0dHA6Ly9saXN0cy5pbmZyYWRlYWQub3JnL21haWxtYW4v bGlzdGluZm8vbGludXgtbXRkLwo=