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 E178ACAC58E for ; Thu, 11 Sep 2025 13:57:19 +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=+e//dmLRd+2YzhaKJ6g1A41pgyEbFI+82G0YsMWe1pk=; b=dPe3MXUkfK79EN wHR3dKpjnJyRqL6XBBzVD6F4RHMlmKwoD7k0Gwvo75ZWjM4EMsb7c1TVruqVV2gfZCNfsrCHdxcEJ rAeFT9uLL/7Nyib9/F3Ij1jmYfqb/7AYmn/am4mjkKv0XMYabp/oCtqyNfl1UIPSptdvO37labehv iVk1zO6SgCasGUQyFuPAyn3DnPAYr6hieevPx/aY+9PUf9LUbdipf/xtT8ZBet9JA+JkxqKLwQk8r nHbcVKv4zMnOdxgi3kPf6Yz+TZlh7UPqP5rZC5aAoEZqSpDSsBNAo9e5c/gpzfkt2NKiUhHulsx5T M7JxMtsutxULcs5+P/1g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1uwhnY-00000003P5j-3UgK; Thu, 11 Sep 2025 13:57:16 +0000 Received: from smtpout-04.galae.net ([185.171.202.116]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1uwhnV-00000003P38-25Px for linux-mtd@lists.infradead.org; Thu, 11 Sep 2025 13:57:15 +0000 Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-04.galae.net (Postfix) with ESMTPS id 9C4DEC6B3BD; Thu, 11 Sep 2025 13:56:51 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id 73D0160630; Thu, 11 Sep 2025 13:57:07 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id A837E102F28F0; Thu, 11 Sep 2025 15:56:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1757599026; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=+8MOtjR/SCOGwiIdk6r9cBes34StJlpvtG+zzPpGcNk=; b=E8XgB5JLS/mPkRP1zvTiKqUhwKzCA50gJAmpUmbn01XBtfVmKS4Mmx2LW+weWFYiXbLH8B 7U+nZamCADWhQ7XINEFNoWGdB6kbpB2qEKCacWxQ2puVuYq/3970GdAsI/HvDBhLCYI8a6 THjK6d4knuwr10/hrmHRGtt4684EiGcs9uAoFv8id8p42I1TgMzZQ+wTUsiwHWgitCRJV5 A4gtTMa0gNDS1DmQ9wLQkI4ZVAVL9rdt227qpHd/5W4ml06QAyFjhTILEGmzZzoh/rLZAU TMgyahAWNFF02OROSkqTXN1H4J7HdvZERF+ls+yJlZ0wezFot/vxH8S4YrQJ1g== From: Miquel Raynal To: Cheng Ming Lin Cc: richard@nod.at, vigneshr@ti.com, robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org, tudor.ambarus@linaro.org, mmkurbanov@salutedevices.com, Takahiro.Kuwano@infineon.com, pratyush@kernel.org, linux-mtd@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, alvinzhou@mxic.com.tw, Cheng Ming Lin Subject: Re: [PATCH v2 1/3] dt-bindings: mtd: spi-nand: Add enable-randomizer-otp property In-Reply-To: (Cheng Ming Lin's message of "Thu, 11 Sep 2025 16:30:11 +0800") References: <20250910030301.1368372-1-linchengming884@gmail.com> <20250910030301.1368372-2-linchengming884@gmail.com> <87wm66d67k.fsf@bootlin.com> <878qilbes9.fsf@bootlin.com> User-Agent: mu4e 1.12.7; emacs 30.1 Date: Thu, 11 Sep 2025 15:56:42 +0200 Message-ID: <87wm659jol.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-20250911_065713_928892_0C9D04EA X-CRM114-Status: GOOD ( 42.86 ) 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 SGksCgo+PiA+PiBUaGlzIGlzIGEgTkFORCB3aWRlIGZlYXR1cmUsIHNvIHdlIHNob3VsZCBwcm9i YWJseSBhZGQgYSBwcmVmaXgsIHN1Y2ggYXMKPj4gPj4gIm5hbmQsIi4KPj4gPj4KPj4gPj4gTm93 LCB3aGF0IGFib3V0IHRoaXMgIm90cCIgc3VmZml4PyBNYW55IChpZiBub3QgYWxsKSBjaGlwcyBo YXZlIGEKPj4gPj4gdm9sYXRpbGUgc2V0dGluZyBmb3IgdGhhdC4gQWJvdXQgdGhlIG5hbWluZywg Im90cCIgb2Z0ZW4gcmVmbGVjdHMgdG8gdGhlCj4+ID4+IE9UUCBhcmVhLCB3aGljaCBpcyBub3Qg d2hhdCB5b3UgaW1wbHkgaGVyZSwgYXMgeW91IHdhbnQgdG8gaW5zaXN0Cj4+ID4+IChyaWdodGZ1 bGx5KSBvbiB0aGUgZmFjdCB0aGF0IHRoaXMgZmVhdHVyZSBjYW5ub3QgYmUgZGlzYWJsZWQuCj4+ ID4KPj4gPiBZZXMsIG15IGludGVudGlvbiBpcyB0aGF0IG9uY2UgdGhlIHJhbmRvbWl6ZXIgZmVh dHVyZSBpcyBlbmFibGVkLCBpdAo+PiA+IHNob3VsZCBub3QgYmUgZGlzYWJsZWQgYWdhaW4uCj4+ Cj4+IEkgYmVsaWV2ZSB0aGUgbW90aXZhdGlvbiBiZWhpbmQgdGhpcyBjaG9pY2UgaXMgaW5jb3Jy ZWN0IGFuZCBkb2VzIG5vdAo+PiBmaXQgc3VjaCBhbiBPUyBhcyBMaW51eC4gV2Ugd2FudCB0byBn aXZlIHRoZSBzeXN0ZW0gYWRtaW5pc3RyYXRvciB0aGUKPj4gY2hvaWNlIHRvIHNlbGVjdCBhbmQg dW5zZWxlY3QgZmVhdHVyZXMgYXMgaXQgc2VlcyBmaXQuIFNvIGlmIHRoZXJlIGlzIGEKPj4gdm9s YXRpbGUgd2F5IHRvIGVuYWJsZSBzb21ldGhpbmcsIHdlIHNob3VsZCBnbyBmb3IgaXQgYW5kIHdl IHdpbGwgcGF5Cj4+IHRoZSBleHRyYSBwZW5hbHR5IG9mIGEgc2V0X2ZlYXR1cmUoKSAob3Igd2hh dGV2ZXIpIGNvbW1hbmQgYWZ0ZXIgZWFjaAo+PiBib290LiBNYWtpbmcgdGhpcyB0eXBlIG9mIGNo YW5nZSBwZXJtYW5lbnQgbWFrZXMgZGV2ZWxvcG1lbnQgYW5kCj4+IGRlYnVnZ2luZyBtdWNoIG1v cmUgcGFpbmZ1bC4gVGhlcmUgYXJlIHBsZW50eSBvZiBjb25maWd1cmF0aW9ucyB0aGF0IHdlCj4+ IHJlZnVzZSB0byBhcHBseSB3aXRoIG5vbiB2b2xhdGlsZSBjb25maWd1cmF0aW9ucy4gSW4gZ2Vu ZXJhbCwgc3RhdGVmdWwKPj4gbW9kZXMgYXJlIHByb2JsZW1hdGljIGlmIHRoZXkgYXJlIGtlcHQg YWZ0ZXIgYSByZWJvb3QgYW5kIHdlIHRyeSBvdXIKPj4gYmVzdCB0byBhdm9pZCB0aGVtLgo+Pgo+ PiBPbmNlIHRoaXMgZmVhdHVyZSBpcyBlbmFibGVkLCBmb3IgdGhlIGxpZmV0aW1lIG9mICJhIHBy b2R1Y3QiLCBpdCBkb2VzCj4+IG5vdCBtYWtlIHNlbnNlIHRvIGRpc2FibGUgaXQgaW5kZWVkLiBB bmQgdGhlIERUIG11c3QgcmVtYWluIGNvcnJlY3QsIGlmCj4+IGl0IGlzIGNoYW5nZWQgaW4gYSBu b24gY29tcGF0aWJsZSB3YXksIHRoYXQncyB0aGUgYWRtaW5pc3RyYXRvcgo+PiByZXNwb25zaWJp bGl0eS4KPj4KPj4gU28gYXJlIHRoZXJlIHdheXMgdG8gZW5hYmxlIHRoaXMgZmVhdHVyZSBpbiBh IHdheSB0aGF0IHJldHVybnMgdG8gdGhlCj4+IGRlZmF1bHQgc3RhdGUgYWZ0ZXIgYSByZXNldD8K Pgo+IFRoYW5rIHlvdSBmb3IgdGhlIGRldGFpbGVkIGZlZWRiYWNrLiBJIHVuZGVyc3RhbmQgYW5k IGFncmVlIHdpdGggdGhlCj4gcHJpbmNpcGxlIG9mIGZhdm9yaW5nIHZvbGF0aWxlIGNvbmZpZ3Vy YXRpb25zIHRvIGdpdmUgYWRtaW5pc3RyYXRvcnMKPiBtb3JlIGNvbnRyb2wgYW5kIHNpbXBsaWZ5 IGRlYnVnZ2luZy4KPgo+IFllcywgaXQgaXMgcG9zc2libGUgdG8gZW5hYmxlIHRoaXMgZmVhdHVy ZSBpbiBhIHdheSB0aGF0IGl0IHJldHVybnMKPiB0byB0aGUgZGVmYXVsdCBzdGF0ZSBhZnRlciBh IHJlc2V0Lgo+Cj4gV2UgY2FuIHVzZSB0aGUgc3RhbmRhcmQgc2V0X2ZlYXR1cmUgY29tbWFuZCB0 byBzZXQgdGhlIFJBTkRFTiBiaXQgdG8gMSwKPiB3aGljaCBlbmFibGVzIHRoZSByYW5kb21pemVy LiBUaGlzIGNvbmZpZ3VyYXRpb24gaXMgdm9sYXRpbGUgYW5kIHdpbGwKPiBub3QgcGVyc2lzdCB0 aHJvdWdoIGEgcG93ZXIgY3ljbGUuIFRoZSBmZWF0dXJlIHdpbGwgcmVtYWluIGRpc2FibGVkIGJ5 Cj4gZGVmYXVsdCBvbiBlYWNoIGJvb3QgdW5sZXNzIGl0IGlzIGV4cGxpY2l0bHkgZW5hYmxlZCBh Z2Fpbi4KPgo+IEkgd2lsbCB1cGRhdGUgdGhlIHBhdGNoIHRvIGltcGxlbWVudCB0aGlzIHZvbGF0 aWxlIGFwcHJvYWNoLgoKSSB3b3VsZCBiZSBpbiBmYXZvdXIgb2YgaW1wbGVtZW50aW5nIHRoaXMg bWV0aG9kLiBIZW5jZSwgbm8gbW9yZSBPVFAKY29uc3RyYWludCB0byBleHByZXNzIGluIHRoZSBi aW5kaW5nIGVpdGhlci4KCj4+ID4gWW91IGFyZSBjb3JyZWN0IHRoYXQgdGhpcyBiaXQgZG9lcyBu b3QKPj4gPiBiZWxvbmcgdG8gdGhlIE9UUCBhcmVhLCBidXQgcmF0aGVyIHRvIHRoZSB2MiB2b2xh dGlsZSByZWdpc3Rlci4gVGhlIHYyCj4+ID4gdm9sYXRpbGUgcmVnaXN0ZXIgaGFzIGEgZGVmYXVs dCB2YWx1ZSB0aGF0IGNhbiBiZSBjaGFuZ2VkIHRocm91Z2ggYQo+PiA+IHNwZWNpYWwgT1RQIGNv bmZpZ3VyYXRpb24gcmVnaXN0ZXIgcHJvZ3JhbSBvcGVyYXRpb24uIFJlZ2FyZGluZyB0aGUKPj4g PiAib3RwIiBzdWZmaXgsIEkgd2lsbCByZW1vdmUgaXQgdG8gYXZvaWQgbWlzdW5kZXJzdGFuZGlu Zy4KPj4gPgo+PiA+Pgo+PiA+PiBBbHNvLCB0aGlzIGlzIGEgcGVyLWNoaXAgY29uZmlndXJhdGlv biwgd2hpbGUgSSB3b3VsZCBoYXZlIHdlbGNvbWVkIGEKPj4gPj4gcGVyLXBhcnRpdGlvbiBjb25m aWd1cmF0aW9uLiBJIGNhbiBlYXNpbHkgaW1hZ2luZSB0d28gY2FzZXM6Cj4+ID4+Cj4+ID4+IC0g VGhlIGJvb3QgUk9NLCBmb3IgbG9uZ2V2aXR5IHB1cnBvc2VzLCBleHBlY3RzIHRoZSBmaXJzdCBi bG9ja3MKPj4gPj4gICBjb250YWluaW5nIHRoZSBib290bG9hZGVyIHRvIGJlIHNjcmFtYmxlZC4g SG93ZXZlciB0aGUgcmVzdCBvZiB0aGUKPj4gPj4gICBzeXN0ZW0gZG9lcyBub3QgcmVhbGx5IGNh cmUgYW5kIGRpc2FibGVzIHJhbmRvbWl6YXRpb24uCj4+ID4+Cj4+ID4+IC0gVGhlIGJvb3QgUk9N IGlzIG5vdCBjYXBhYmxlIG9mIGRlLXNjcmFtYmxpbmcsIGhvd2V2ZXIgdGhlIHJlc3Qgb2YgdGhl Cj4+ID4+ICAgc3lzdGVtIHJlbGllcyBvbiB0aGUgKHByb2JhYmx5KSBtb3JlIHJvYnVzdCBzY3Jh bWJsaW5nIGZlYXR1cmUuCj4+ID4+Cj4+ID4+IEluIGJvdGggY2FzZXMgYSBjaGlwIHdpZGUgdmFy aWFibGUgaXMgbm90IHJlbGV2YW50Lgo+PiA+Cj4+ID4gVGhlIHNjcmFtYmxpbmcgYW5kIGRlc2Ny YW1ibGluZyBhcmUgaGFuZGxlZCBieSB0aGUgTkFORCBmbGFzaCBoYXJkd2FyZQo+PiA+IGl0c2Vs Zi4gVGhlcmVmb3JlLCB0aGUgYm9vdCBST00gZG9lcyBub3QgbmVlZCB0byBzdXBwb3J0IGEgZGVz Y3JhbWJsaW5nCj4+ID4gZmVhdHVyZS4KPj4gPgo+PiA+IEluIHRoZSBjYXNlIG9mIE1hY3Jvbml4 IHBhcnRzLCB0aGUgcmFuZG9taXplciBpcyBjb250cm9sbGVkIHRocm91Z2ggYQo+PiA+IGNvbmZp Z3VyYXRpb24gcmVnaXN0ZXIsIGFuZCBvbmNlIGl0IGlzIGVuYWJsZWQgaXQgY292ZXJzIHRoZSBl bnRpcmUgY2hpcAo+PiA+IChtYWluIGFuZC9vciBzcGFyZSBkZXBlbmRpbmcgb24gdGhlIHJhbmRv cHQgYml0KS4gVGhlcmUgaXMgbm8gaGFyZHdhcmUKPj4gPiBtZWNoYW5pc20gdG8gZW5hYmxlIGl0 IG9ubHkgb24gY2VydGFpbiByYW5nZXMuCj4+Cj4+IEFmdGVyIHRoaW5raW5nIG9uY2UgYWdhaW4s IEkgYW0gbm8gbG9uZ2VyIGFsaWduZWQgd2l0aCBteXNlbGYgZnJvbSB0aGUKPj4gcGFzdC4gVGhp cyBpcyBwZXJoYXBzIHRvbyBNYWNyb25peCBzcGVjaWZpYyBpbiB0aGUgZW5kIGFuZCBpZiBpdCBp cyBhCj4+IGZ1bGx5IHRyYW5zcGFyZW50IGZlYXR1cmUsIHRoZW4gd2h5IG5vdC4KPj4KPj4gQXJl IHRoZXJlIGFueSB3YXlzIHdlIGNhbiByZWFkIHRoZSByYXcgZGF0YSAodW5zY3JhbWJsZWQpIG9u Y2UKPj4gc2NyYW1ibGluZyBoYXMgYmVlbiBlbmFibGVkPyAoSSBtZWFuLCB3aXRob3V0IGNoYW5n aW5nIHRoZSB1c2VyIGRlZmF1bHQKPj4gT1RQIHN0YXRlKS4gTWF5YmUgb25lIGJpZyBkaWZmZXJl bmNlIHdpdGggdGhlIHJhdyBOQU5EIHdvcmxkIHRoYXQgbmVlZHMKPj4gdG8gYmUgdGFrZW4gaW50 byBhY2NvdW50IGlzIHRoYXQgdGhlIGNoaXAgaXRzZWxmIGFsd2F5cyByZXR1cm4KPj4gdW5zY3Jh bWJsZWQgZGF0YSwgaGVuY2Ugd2UgcHJvYmFibHkgZG8gbm90IGNhcmUgbXVjaCwgZnJvbSBhIExp bnV4Cj4+IHBlcnNwZWN0aXZlLgo+Cj4gVW5mb3J0dW5hdGVseSwgdGhlcmUgaXMgbm8gd2F5IHRv IGRvIHRoaXMuIElmIGEgdXNlciBkZWNpZGVzIHRvIHVzZSB0aGUKPiByYW5kb21pemVyIGZlYXR1 cmUsIHRoZXkgbXVzdCBlbmFibGUgaXQgYmVmb3JlIHByb2dyYW1taW5nIHRoZSB1c2VyIE9UUAo+ IGFyZWEuIElmIHRoZSByYW5kb21pemVyIGlzIG5vdCBlbmFibGVkIGJlZm9yZSB0aGUgdXNlciBP VFAgaXMgcHJvZ3JhbW1lZCwKPiBhbnkgc3Vic2VxdWVudCByZWFkcyB3aWxsIHJlc3VsdCBpbiBj b3JydXB0ZWQgZGF0YS4KPgo+IE1hcmNvbml4IHJhdyBOQU5EIGNoaXAgaXRzZWxmIGRvZXMgbm90 IGFsd2F5cyByZXR1cm4gdW5zY3JhbWJsZWQgZGF0YS4KPgo+IFRoZSBhYmlsaXR5IHRvIHJlYWQg dW5zY3JhbWJsZWQgZGF0YSBpcyBkZXBlbmRlbnQgb24gd2hldGhlciB0aGUKPiByYW5kb21pemVy IGZlYXR1cmUgd2FzIGVuYWJsZWQgYW5kIGNvbmZpZ3VyZWQgY29ycmVjdGx5LiBXaGVuIHRoZQo+ IHJhbmRvbWl6ZXIgaXMgdHVybmVkIG9uLCB0aGUgY2hpcCdzIGludGVybmFsIGhhcmR3YXJlIGF1 dG9tYXRpY2FsbHkKPiBoYW5kbGVzIHRoZSB1bnNjcmFtYmxpbmcgcHJvY2Vzcy4gSWYgdGhlIGZl YXR1cmUgaXMgbm90IGVuYWJsZWQsIHRoZQo+IGRhdGEgcmVhZCBmcm9tIHRoZSBtZW1vcnkgd2ls bCBiZSB0aGUgcmF3LCBzY3JhbWJsZWQgaW5mb3JtYXRpb24sIHdoaWNoCj4gaXMgdW51c2FibGUg d2l0aG91dCB0aGUgY29ycmVjdCBrZXkgYW5kIGFsZ29yaXRobS4gSW4gb3RoZXIgd29yZHMsIHRo ZQo+IGNoaXAgb25seSByZXR1cm5zIHVuc2NyYW1ibGVkIGRhdGEgaWYgcmFuZG9taXplciBmZWF0 dXJlIGlzIGVuYWJsZWQuCgpUaGF0IGlzIGludGVyZXN0aW5nIGFuZCBtaWdodCBiZSB1c2VmdWwu IEluIExpbnV4IHdlIHdpbGwgZW5hYmxlIHRoZQpzY3JhbWJsZXIgaWYgdGhlIGRhdGEgcHJvcGVy dHkgaXMgZW5hYmxlZCBiZWZvcmUgd2UgZ2V0IHRvIHBsYXkgd2l0aCB0aGUKT1RQIGFueXdheSwg c28gaG9wZWZ1bGx5IHBlb3BsZSB3aWxsIGdldCBpdCByaWdodC4KClJlZ2FyZGluZyB0aGUgcHJv cGVydHkgbmFtZSwgaXQgaXMgZ29pbmcgdG8gYmUgYSBwZXIgU1BJIE5BTkQgY2hpcApwcm9wZXJ0 eS4gSSBhbSBzdGlsbCBub3Qgc3VyZSB3aGV0aGVyIHdlIHNob3VsZCBtYWtlIHRoaXMgcHJvcCBn ZW5lcmljCm9yIG5vdC4gUGVyaGFwcyB0aGUgc2FmZXN0IGFwcHJvYWNoIGlzIHRvIGtlZXAgaXQg dmVuZG9yIHNwZWNpZmljLCBidXQKdGhlIGNvbmNlcHQgb2Ygc2NyYW1ibGluZyBpbnRlcm5hbCBk YXRhIGZvciBsb25nZXZpdHkgcHVycG9zZXMgaXMgY29tbW9uCmVub3VnaCB0byBkZXNlcnZlIGEg bmFuZC0gcHJlZml4LiBBbHRob3VnaCBpdCdzIGdvbm5hIGJlIGxpa2UgRUNDCmVuZ2luZXMsIHdl J2xsIG5lZWQgdG8gZGVjaWRlIHdoaWNoIHBhcnQgb2YgdGhlIHN5c3RlbSBoYW5kbGVzIHRoZQpz Y3JhbWJsaW5nIChzb2Z0d2FyZSwgaGFyZHdhcmUgb24gaG9zdCBvciBjaGlwIGl0c2VsZikgYW5k IHdoZXRoZXIgaXQgaXMKZW5hYmxlZCBwZXItY2hpcCBvciBwZXItcGFydGl0aW9uIHdoZW4gdGhh dCdzIHBvc3NpYmxlLgoKSSBhbSBvcGVuIHRvIHN1Z2dlc3Rpb25zLgoKVGhhbmtzLApNaXF1w6hs CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K TGludXggTVREIGRpc2N1c3Npb24gbWFpbGluZyBsaXN0Cmh0dHA6Ly9saXN0cy5pbmZyYWRlYWQu b3JnL21haWxtYW4vbGlzdGluZm8vbGludXgtbXRkLwo= From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtpout-02.galae.net (smtpout-02.galae.net [185.246.84.56]) (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 4BB3432F751 for ; Thu, 11 Sep 2025 13:57:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.246.84.56 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757599032; cv=none; b=I8CXC2eaIPMwp+R0WJdXQEuDCypRO2igbgPFT2M3XKhLReKiKKagatlHyZw344/BWKrbEoMR6noZiL06rPZtSTwZOt1j9I+X+j1SdW52928709iy49tFG2GkGIjafBzMnJB3vPEUCeF5AVwBp9ct67Qdkr2zJFBLTOcyIcJEMq8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757599032; c=relaxed/simple; bh=oDf5VY2SMDhWKzWUCn3C1u6sbTRxHqiOGBPOElxerfE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=bSFzOh7gC3gwOk6wTrLM7NR6pS66MNItfevZdO0U5Rl+PedQizFf7bjPIcUxYnF+RY69pXskKS2RPqYxIarBlZaRtJRdQsWFG65X7Ka/0tmg5o12jY4GW1zB0TlvHN+ahbnE6kyKGeCa3sFgDoG8CHa83VJwtbdz5LAwgwDvmFc= 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=E8XgB5JL; arc=none smtp.client-ip=185.246.84.56 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="E8XgB5JL" Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-02.galae.net (Postfix) with ESMTPS id A05CD1A0DD7; Thu, 11 Sep 2025 13:57:07 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id 73D0160630; Thu, 11 Sep 2025 13:57:07 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id A837E102F28F0; Thu, 11 Sep 2025 15:56:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1757599026; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=+8MOtjR/SCOGwiIdk6r9cBes34StJlpvtG+zzPpGcNk=; b=E8XgB5JLS/mPkRP1zvTiKqUhwKzCA50gJAmpUmbn01XBtfVmKS4Mmx2LW+weWFYiXbLH8B 7U+nZamCADWhQ7XINEFNoWGdB6kbpB2qEKCacWxQ2puVuYq/3970GdAsI/HvDBhLCYI8a6 THjK6d4knuwr10/hrmHRGtt4684EiGcs9uAoFv8id8p42I1TgMzZQ+wTUsiwHWgitCRJV5 A4gtTMa0gNDS1DmQ9wLQkI4ZVAVL9rdt227qpHd/5W4ml06QAyFjhTILEGmzZzoh/rLZAU TMgyahAWNFF02OROSkqTXN1H4J7HdvZERF+ls+yJlZ0wezFot/vxH8S4YrQJ1g== From: Miquel Raynal To: Cheng Ming Lin Cc: richard@nod.at, vigneshr@ti.com, robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org, tudor.ambarus@linaro.org, mmkurbanov@salutedevices.com, Takahiro.Kuwano@infineon.com, pratyush@kernel.org, linux-mtd@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, alvinzhou@mxic.com.tw, Cheng Ming Lin Subject: Re: [PATCH v2 1/3] dt-bindings: mtd: spi-nand: Add enable-randomizer-otp property In-Reply-To: (Cheng Ming Lin's message of "Thu, 11 Sep 2025 16:30:11 +0800") References: <20250910030301.1368372-1-linchengming884@gmail.com> <20250910030301.1368372-2-linchengming884@gmail.com> <87wm66d67k.fsf@bootlin.com> <878qilbes9.fsf@bootlin.com> User-Agent: mu4e 1.12.7; emacs 30.1 Date: Thu, 11 Sep 2025 15:56:42 +0200 Message-ID: <87wm659jol.fsf@bootlin.com> Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org 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, >> >> This is a NAND wide feature, so we should probably add a prefix, such= as >> >> "nand,". >> >> >> >> Now, what about this "otp" suffix? Many (if not all) chips have a >> >> volatile setting for that. About the naming, "otp" often reflects to = the >> >> OTP area, which is not what you imply here, as you want to insist >> >> (rightfully) on the fact that this feature cannot be disabled. >> > >> > Yes, my intention is that once the randomizer feature is enabled, it >> > should not be disabled again. >> >> I believe the motivation behind this choice is incorrect and does not >> fit such an OS as Linux. We want to give the system administrator the >> choice to select and unselect features as it sees fit. So if there is a >> volatile way to enable something, we should go for it and we will pay >> the extra penalty of a set_feature() (or whatever) command after each >> boot. Making this type of change permanent makes development and >> debugging much more painful. There are plenty of configurations that we >> refuse to apply with non volatile configurations. In general, stateful >> modes are problematic if they are kept after a reboot and we try our >> best to avoid them. >> >> Once this feature is enabled, for the lifetime of "a product", it does >> not make sense to disable it indeed. And the DT must remain correct, if >> it is changed in a non compatible way, that's the administrator >> responsibility. >> >> So are there ways to enable this feature in a way that returns to the >> default state after a reset? > > Thank you for the detailed feedback. I understand and agree with the > principle of favoring volatile configurations to give administrators > more control and simplify debugging. > > Yes, it is possible to enable this feature in a way that it returns > to the default state after a reset. > > We can use the standard set_feature command to set the RANDEN bit to 1, > which enables the randomizer. This configuration is volatile and will > not persist through a power cycle. The feature will remain disabled by > default on each boot unless it is explicitly enabled again. > > I will update the patch to implement this volatile approach. I would be in favour of implementing this method. Hence, no more OTP constraint to express in the binding either. >> > You are correct that this bit does not >> > belong to the OTP area, but rather to the v2 volatile register. The v2 >> > volatile register has a default value that can be changed through a >> > special OTP configuration register program operation. Regarding the >> > "otp" suffix, I will remove it to avoid misunderstanding. >> > >> >> >> >> Also, this is a per-chip configuration, while I would have welcomed a >> >> per-partition configuration. I can easily imagine two cases: >> >> >> >> - The boot ROM, for longevity purposes, expects the first blocks >> >> containing the bootloader to be scrambled. However the rest of the >> >> system does not really care and disables randomization. >> >> >> >> - The boot ROM is not capable of de-scrambling, however the rest of t= he >> >> system relies on the (probably) more robust scrambling feature. >> >> >> >> In both cases a chip wide variable is not relevant. >> > >> > The scrambling and descrambling are handled by the NAND flash hardware >> > itself. Therefore, the boot ROM does not need to support a descrambling >> > feature. >> > >> > In the case of Macronix parts, the randomizer is controlled through a >> > configuration register, and once it is enabled it covers the entire ch= ip >> > (main and/or spare depending on the randopt bit). There is no hardware >> > mechanism to enable it only on certain ranges. >> >> After thinking once again, I am no longer aligned with myself from the >> past. This is perhaps too Macronix specific in the end and if it is a >> fully transparent feature, then why not. >> >> Are there any ways we can read the raw data (unscrambled) once >> scrambling has been enabled? (I mean, without changing the user default >> OTP state). Maybe one big difference with the raw NAND world that needs >> to be taken into account is that the chip itself always return >> unscrambled data, hence we probably do not care much, from a Linux >> perspective. > > Unfortunately, there is no way to do this. If a user decides to use the > randomizer feature, they must enable it before programming the user OTP > area. If the randomizer is not enabled before the user OTP is programmed, > any subsequent reads will result in corrupted data. > > Marconix raw NAND chip itself does not always return unscrambled data. > > The ability to read unscrambled data is dependent on whether the > randomizer feature was enabled and configured correctly. When the > randomizer is turned on, the chip's internal hardware automatically > handles the unscrambling process. If the feature is not enabled, the > data read from the memory will be the raw, scrambled information, which > is unusable without the correct key and algorithm. In other words, the > chip only returns unscrambled data if randomizer feature is enabled. That is interesting and might be useful. In Linux we will enable the scrambler if the data property is enabled before we get to play with the OTP anyway, so hopefully people will get it right. Regarding the property name, it is going to be a per SPI NAND chip property. I am still not sure whether we should make this prop generic or not. Perhaps the safest approach is to keep it vendor specific, but the concept of scrambling internal data for longevity purposes is common enough to deserve a nand- prefix. Although it's gonna be like ECC engines, we'll need to decide which part of the system handles the scrambling (software, hardware on host or chip itself) and whether it is enabled per-chip or per-partition when that's possible. I am open to suggestions. Thanks, Miqu=C3=A8l