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 950B5D1AD2E for ; Wed, 16 Oct 2024 09:01: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:References:In-Reply-To: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=4qzJEAlUnSdTQRTbxFjxFIvEHVkA/3pg/WnNbm/VzgQ=; b=Rc1XFnvBtV4Md+ 6r7C4yuY5nxmkZ3T8BLTtVgZXLUuYMOtrignyVU12cEnlv3563cpHSVG2kdlS6WPljLTxRDSeUEkz WuR+r/lGuYs5Sln3okJgDkmlU58YHOypwbGHiPF8siPQ7K4L9cof3gfFN/SSQeA6hYjx865WaeMOI E7WXBMGOxvZqA1Ylu8sNOv4e+BAagRuqAzUU3slvEkhMjehnNtzLXRpNgDoEkoaSv3xjs/wkys1yu YrvNmmpotqpcZMXE7k2tj/Ib23xtGd2zRB6vbXt2uxvIrcfZS9IV+7i+fyAENdn1fRZT4z+mn1UQw mp/D2IumMDE2W/7Yr4ow==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1t0zuJ-0000000B90O-2iFc; Wed, 16 Oct 2024 09:01:27 +0000 Received: from relay1-d.mail.gandi.net ([2001:4b98:dc4:8::221]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1t0zrV-0000000B8UQ-1rPZ for linux-mtd@lists.infradead.org; Wed, 16 Oct 2024 08:58:35 +0000 Received: by mail.gandi.net (Postfix) with ESMTPSA id C8FAE240008; Wed, 16 Oct 2024 08:58:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1729069109; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=x3U/ETveGyfKnjLcVyYOTm+ngXWvKY86THZrnq130qU=; b=CrynI8QCFY+rV6CUfg7oqNg5Cn+axWaZvu7why2KR7lINNVmbCFmYzoaV/z7/evseoEgkG CMupTxXlD0rF9cm6UkwEwGYZRoofd7GLOm9aSc5zQdX7l7EK0mIPk1p0m2slbJi/kitpY2 r5irEDbDgCDXsmVvpMqVen3IBSKf93tn7szEEkbY8UKTnsUxBAEmQHLnJTjzz1fpjbkPVk 9eOGicU+Yfa6iKRHmzRbfxJ85A8E4jvjqHOrDMeGzuFTcaAJR6SC5DoCwlopXjcilEjSXL iowz7wqk8gWADsiWx5xhNSc2wthSPU3G6hjJlfOFOZEsucpUbduPKlgPlY81yg== Date: Wed, 16 Oct 2024 10:58:27 +0200 From: Miquel Raynal To: Christian Marangi Cc: Richard Weinberger , Vignesh Raghavendra , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Saravana Kannan , Florian Fainelli , Thomas Bogendoerfer , Wolfram Sang , linux-mtd@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Lorenzo Bianconi , upstream@airoha.com Subject: Re: [PATCH 2/3] dt-bindings: mtd: Add Documentation for Airoha fixed-partitions Message-ID: <20241016105827.22a6bb45@xps-13> In-Reply-To: <670f6c5e.170a0220.373da5.7bb7@mx.google.com> References: <20240925101422.8373-3-ansuelsmth@gmail.com> <20240925133003.619c40c4@xps-13> <66f3f58e.5d0a0220.5d655.b48a@mx.google.com> <20240925135256.32d3a0f7@xps-13> <66f3fcb7.5d0a0220.3ca4c2.ba83@mx.google.com> <20240930114819.609f9341@xps-13> <66fa7915.050a0220.1da288.aeca@mx.google.com> <20241001104225.67483dab@xps-13> <66fbcee8.df0a0220.2ad0cb.4f6a@mx.google.com> <20241002100006.5995fd10@xps-13> <670f6c5e.170a0220.373da5.7bb7@mx.google.com> Organization: Bootlin X-Mailer: Claws Mail 4.2.0 (GTK 3.24.41; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-GND-Sasl: miquel.raynal@bootlin.com X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20241016_015833_950491_D41D5BD8 X-CRM114-Status: GOOD ( 60.85 ) 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 SGkgQ2hyaXN0aWFuLAoKYW5zdWVsc210aEBnbWFpbC5jb20gd3JvdGUgb24gV2VkLCAxNiBPY3Qg MjAyNCAwOTozMzo0NiArMDIwMDoKCj4gT24gV2VkLCBPY3QgMDIsIDIwMjQgYXQgMTA6MDA6MDZB TSArMDIwMCwgTWlxdWVsIFJheW5hbCB3cm90ZToKPiA+IEhpIENocmlzdGlhbiwKPiA+ICAgCj4g PiA+ID4gPiA+ID4gT2sgcHJvYmFibHkgdGhlIGRlc2NyaXB0aW9uIGlzbid0IGNsZWFyIGVub3Vn aC4gVGhlIG1pc3NpbmcgaW5mbyB0aGF0Cj4gPiA+ID4gPiA+ID4gcmVxdWlyZSB0aGlzIHBhcnNl ciBpcyB0aGUgZmxhc2ggZW5kLgo+ID4gPiA+ID4gPiA+IAo+ID4gPiA+ID4gPiA+IEZvbGxvd2lu ZyB0aGUgZXhhbXBsZSB3ZSBrbm93IHRoZSBzaXplIG9mIHJvb3Rmc19kYXRhIGFuZCBzdGFydCBv ZmZzZXQKPiA+ID4gPiA+ID4gPiBBTkQgd2Uga25vdyB0aGUgc2l6ZSBvZiB0aGUgQVJUIHBhcnRp dGlvbi4KPiA+ID4gPiA+ID4gPiAKPiA+ID4gPiA+ID4gPiBUaGVyZSBtaWdodCBiZSBhIHNwYWNl IGluIHRoZSBtaWRkbGUgdW51c2VkIGJldHdlZW4gdGhlIHJvb3Rmc19kYXRhCj4gPiA+ID4gPiA+ ID4gcGFydGl0aW9uIGFuZCB0aGUgYXJ0IHBhcnRpdGlvbi4gV2hhdCBpcyBkZXJpdmVkIGlzIHRo ZSBzdGFydGluZyBvZmZzZXQKPiA+ID4gPiA+ID4gPiBvZiB0aGUgYXJ0IHBhcnRpdGlvbiB0aGF0 IGlzIGZsYXNoIGVuZCAtIGFydCBwYXJ0aXRpb24gc2l6ZS4KPiA+ID4gPiA+ID4gPiAod2hlcmUg Zmxhc2ggZW5kIGNoYW5nZSBhbmQgaXMgbm90IGFsd2F5cyB0aGUgc2FtZSBkdWUgdG8gaG93IHRo ZSBzcGVjaWFsCj4gPiA+ID4gPiA+ID4gYmFkIGJsb2NrIG1hbmFnYW1lbnQgdGFibGUgcmVzZXJ2 ZWQgc3BhY2UgaXMgaGFuZGxlZCkKPiA+ID4gPiA+ID4gPiAKPiA+ID4gPiA+ID4gPiBUaGlzIGlz IHdoeSAweGZmZmZmZmZmLCB1c2VkIGFzIGEgZHVtbXkgb2Zmc2V0IHRvIHNpZ25hbCBpdCB3aWxs IGJlIHBhcnNlZCBhdAo+ID4gPiA+ID4gPiA+IHJ1bnRpbWUuIE9uIHNlY29uZCB0b3VnaHQgdGhv IG1heWJlIHVzaW5nIHRoaXMgZHVtbXkgb2Zmc2V0IGlzIHdyb25nIGFuZAo+ID4gPiA+ID4gPiA+ IEkgc2hvdWxkIGp1c3QgaGF2ZSBzb21ldGhpbmcgbGlrZQo+ID4gPiA+ID4gPiA+IAo+ID4gPiA+ ID4gPiA+IGxlbmd0aCA9IDwweDMwMDAwMD47Cj4gPiA+ID4gPiA+ID4gCj4gPiA+ID4gPiA+ID4g SXMgaXQgY2xlYXIgbm93PyBTb3JyeSBmb3IgYW55IGNvbmZ1c2lvbi4gICAgICAKPiA+ID4gPiA+ ID4gCj4gPiA+ID4gPiA+IEknbSBzb3JyeSBidXQgbm90IHJlYWxseS4gWW91IGtub3cgdGhlIGVu ZCBvZiB0aGUgcGh5c2ljYWwgZGV2aWNlIGFuZAo+ID4gPiA+ID4gPiB0aGUgc2l6ZSBvZiB0aGUg QVJUIHBhcnRpdGlvbiwgc28geW91IG11c3Qga25vdyBpdHMgc3RhcnQgYXMgd2VsbD8KPiA+ID4g PiA+ID4gICAgICAKPiA+ID4gPiA+IAo+ID4gPiA+ID4gQmVmb3JlIHRoZSBzeXN0ZW0gYm9vdCB3 ZSBrbm93Ogo+ID4gPiA+ID4gLSBzaXplIG9mIHRoZSBBUlQgcGFydGl0aW9uCj4gPiA+ID4gPiAt IHJlYWwgc2l6ZSBvZiB0aGUgcGh5c2ljYWwgZGV2aWNlICg1MTJtYi4uLiAxRy4uLiA2NG1iLi4u KQo+ID4gPiA+ID4gCj4gPiA+ID4gPiBXaGVuIHRoZSBwaHlzaWNhbCBkZXZpY2UgaXMgcHJvYmVk IChuYW5kKSBhIHNwZWNpYWwgZHJpdmVyIGlzIGxvYWRlZAo+ID4gPiA+ID4gKGJlZm9yZSBtdGQg cGFyc2luZyBsb2dpYykgdGhhdCBjaGFuZ2UgdGhlIHBoeXNpY2FsIHNpemUgb2YgdGhlIGRldmlj ZQo+ID4gPiA+ID4gKG10ZC0+c2l6ZSkgYXMgYXQgdGhlIGVuZCBvZiB0aGUgbmFuZCBzb21lIHNw YWNlIGlzIHJlc2VydmVkIGZvciBiYWQKPiA+ID4gPiA+IGJsb2NrIG1hbmFnZW1lbnQgYW5kIG90 aGVyIG1ldGFkYXRhIGluZm8uICAgIAo+ID4gPiA+IAo+ID4gPiA+IEhlcmUgeW91IGFyZSBleHBs YWluaW5nIHdoYXQgeW91IGludGVuZCBMaW51eCB0byBkbywgcmlnaHQ/IEkgd291bGQKPiA+ID4g PiBsaWtlIHRvIHVuZGVyc3RhbmQgd2hhdCB5b3UgYXJlIHRyeWluZyB0byBzb2x2ZS4gSSBkb250 IHVuZGVyc3RhbmQgd2h5Cj4gPiA+ID4geW91IG5lZWQgdGhlIHNpemUgY2hhbmdlLCBJIGRvbid0 IHVuZGVyc3RhbmQgd2h5IHlvdSBkb24ndCBrbm93IHRoZQo+ID4gPiA+IHN0YXJ0IG9mIHRoZSBB UlQgcGFydGl0aW9uLCBJIGRvbid0IHVuZGVyc3RhbmQgd2hhdCB0aGUgZGF0YSB5b3UgYXJlCj4g PiA+ID4gaGlkaW5nIGNvbnRhaW5zIGFuZCB3aG8gdXNlcyBpdCA6LSkgSSdtIHNvcnJ5LCB0aGlz IGlzIHRvbyB1bmNsZWFyIHlldC4gICAgCj4gPiA+IAo+ID4gPiBUb3RhbGx5IG5vdCBhIHByb2Js ZW0gYW5kIHRoYW5rcyBhIGxvdCBmb3IgeW91IGtlZXAgYXNraW5nIHRoZW0uLi4gTW9yZQo+ID4g PiB0aGFuIGhhcHB5IHRvIGNsZWFyIHRoaW5ncywgSSdtIHRyeWluZyB0byBzb2x2ZSBhIHByb2Js ZW0gcHJlc2VudCBvbgo+ID4gPiBBaXJvaGEgU29DIGFuZCB1cHN0cmVhbWluZyBhIGNvcnJlY3Qg cGFyc2VyIGZvciBpdC4KPiA+ID4gCj4gPiA+IFdoYXQgSSdtIHRyeWluZyB0byBzb2x2ZToKPiA+ ID4gCj4gPiA+IENvcnJlY3QgYWNjZXNzIHRvIHRoaXMgcGFydGl0aW9uIGF0IHRoZSBlbmQgb2Yg dGhlIGZsYXNoIGluIGFuIGF1dG9tYXRlZAo+ID4gPiB3YXkuCj4gPiA+IAo+ID4gPiBUaGUgY29u dGVudCBvZiB0aGlzIHBhcnRpdGlvbiBpcyB0aGUgdXN1YWwgQVJUIHBhcnRpdGlvbiBmb3VuZCBv biBsb3RzIG9mCj4gPiA+IGVtYmVkZGVkIGRldmljZXMuIE1BQyBhZGRyZXNzLCB3aWZpIGNhbGli cmF0aW9uIGRhdGEsIHNlcmlhbC4gVXNhZ2UgaXMKPiA+ID4gTlZNRU0gY2VsbHMgYW5kIHVzZXJz cGFjZSB3aXRoIGRkIGNvbW1hbmQgdG8gZXh0cmFjdCBkYXRhIGZyb20uCj4gPiA+IAo+ID4gPiBB aXJvaGEgdXNlIHNvbWV0aGluZyBhbHNvIHVzZWQgYnkgc29tZSBtZWRpYXRlayBTb0MuIFRoZXkg Y2FsbCBpdCBCTVQKPiA+ID4gYW5kIGl0J3MgY3VycmVudGx5IHVzZWQgZG93bnN0cmVhbSBpbiBP cGVuV3J0IGFuZCB0aGV5IGZpcm13YXJlLiBUaGlzIGlzCj4gPiA+IGFsc28gdXNlZCBpbiB0aGUg Ym9vdGxvYWRlci4KPiA+ID4gCj4gPiA+IFRoZSB1c2FnZSBvZiBCTVQgaXMgYSBjdXN0b20gd2F5 IHRvIGhhbmRsZSBiYWQgYmxvY2tzIGVudGlyZWx5IGJ5Cj4gPiA+IHNvZnR3YXJlLiBBdCB0aGUg ZW5kIG9mIHRoZSBmbGFzaCBzb21lIHNwYWNlIGlzIHJlc2VydmVkIHdoZXJlIGluZm8KPiA+ID4g YWJvdXQgYWxsIHRoZSBibG9ja3Mgb2YgdGhlIGZsYXNoIGFyZSBwdXQuIEknbSBub3QgMTAwJSBz dXJlIGFib3V0IHRoZQo+ID4gPiBmdW5jdGlvbmFsaXR5IG9mIHRoaXMgYnV0IGl0IGNhbiByZWxv Y2F0ZSBibG9jayBhbmQgZG8gbWFnaWMgdGhpbmdzIHRvCj4gPiA+IGhhbmRsZSBiYWQgYmxvY2tz LiBGb3IgdGhlIHNjb3BlIG9mIHRoaXMgY2hhbmdlLCB0aGUgaW1wb3J0YW50IGluZm8gaXMKPiA+ ID4gdGhhdCBhZnRlciB0aGUgQk1UIGlzIHByb2JlZCwgdGhlIG9wZXJhdGlvbiBvZiAicmVzZXJ2 aW5nIHNwYWNlIiBpcyBkb25lCj4gPiA+IGJ5IHJlZHVjaW5nIHRoZSBNVEQgZmxhc2ggc2l6ZS4g U28gZnJvbSB0aGUgTVREIHN1YnN5c3RlbSwgaXQgZG9lcyBzZWUgYQo+ID4gPiBzbWFsbGVyIGZs YXNoIHRoYW4gaXQgYWN0dWFsbHkgaXMuCj4gPiA+IAo+ID4gPiBUaGUgcmVzZXJ2ZWQgc3BhY2Ug Y2hhbmdlISBBY3Jvc3MgU29DIG9yIGV2ZW4gZGV2aWNlcyBidXQgdGhlIEJNVCBpcyBhCj4gPiA+ IG11c3Qgd2hlcmUgaXQncyB1c2VkIGFzIGJvb3Rsb2FkZXIgbWFrZXMgdXNlIG9mIGl0IGFuZCB3 cml0aW5nIHRvIGl0Cj4gPiA+IG1pZ2h0IGNvbmZ1c2UgdGhlIGJvb3Rsb2FkZXIgY29ycnVwdGlu ZyBkYXRhLiAob25lIGJsb2NrIG1pZ2h0IGJlCj4gPiA+IGZsYWdnZWQgYXMgYmFkIGFkIGRhdGEg bW92ZWQsIEJNVCBkcml2ZXIgdmFsaWRhdGVzIGhpcyB0YWJsZSBhbmQgZG8KPiA+ID4gb3BlcmF0 aW9uKSAgCj4gPiAKPiA+IE9rLCBJIHRoaW5rIHRoYXQncyB3YXkgY2xlYXJlciBub3cuCj4gPiAg Cj4gCj4gSGkgc29ycnkgZm9yIHRoZSBkZWxheSwgdmVyeSBoYXBweSB0aGlzIGlzIGJldHRlciBu b3cuCj4gCj4gPiBTbyB0aGUgQk1UIGRyaXZlciBkb2VzIG5vdCBleGlzdCBpbiBtYWlubGluZSBM aW51eCwgYnV0IHlvdSB3b3VsZCBsaWtlCj4gPiB0byBza2lwIHRoaXMgcGFydCBvZiB0aGUgTVRE IGRldmljZSB0byBhdm9pZCBzbWFzaGluZyBpdC4gQW5kIGl0IGlzIGluCj4gPiB1c2UgYnkgdGhl IHZlbmRvciBCb290bG9hZGVyIEkgZ3Vlc3M/ICAKPiAKPiBZZXMgY29ycmVjdCwgaWRlYSBpcyB0 byBwZXJtaXQgZWFzaWVyIGFjY2VzcyB0byB0aGUgcGFydGl0aW9uLiBJIGhvcGUKPiAoYW5kIGFz c3VtZSkgdGhpcyBkcml2ZXIgd2lsbCBjb21lIHVwc3RyZWFtLgo+IAo+ID4gCj4gPiBJcyBpdCBz b21lIGtpbmQgb2YgdGFibGUgdGhhdCBpcyB3cml0dGVuIGJ5IHRoZSBjaGlwIGl0c2VsZiBpbiBv cmRlciB0bwo+ID4gbWFpbnRhaW4gYSBsaXN0IG9mIGF1dG8tcmVwbGFjZW1lbnQgYmxvY2tzIGZv ciBiYWQgYmxvY2tzPyBDYW4gdGhlIHNpemUKPiA+IG9mIHRoaXMgdGFibGUgbW92ZSB3aXRoIHRo ZSB1c2Ugb2YgdGhlIGRldmljZT8gKGlmIHllcywgaXQncwo+ID4gcHJvYmxlbWF0aWMsIHdlIGRv bid0IHdhbnQgdG8gcmVzaXplIE1URCBwYXJ0aXRpb25zIHdpdGhvdXQgbm90aWNpbmcsCj4gPiBp dCB3b3VsZCBicmVhayBlZy4gVUJJKS4KPiA+ICAgCj4gCj4gTm8gY2hpcCBodyBiYWQgYmxvY2sg aXMgZGlzYWJsZWQgd2l0aCB0aGlzIGltcGxlbWVudGF0aW9uIGFuZCB0aGUgdGFibGUKPiBzaXpl IGRvZXNuJ3QgbW92ZS9jaGFuZ2Ugc28gTVREIHBhcnRpdGlvbnMgd2lsbCBzdGF5IGF0IHRoZSBz YW1lIG9mZnNldAo+IGFmdGVyIHRoZSBmaXJzdCBwYXJzZSBvbiBib290Lgo+IAo+ID4gSSBiZWxp ZXZlIHRoaXMgQk1UIGJsb2NrIGlzIGdvaW5nIGFnYWluc3QgdGhlIGJhZCBibG9jayBoYW5kbGlu ZyBpbgo+ID4gTGludXgsIHNvIEkgcmVhbGx5IHdvbmRlciBob3cgb25lIGNhbiB1c2UgYm90aCBt ZWNoYW5pc21zIGluIGEgc3lzdGVtLgo+ID4gSWYgdGhlIEJNVCBsYXllciB0YWtlcyAib25lIHJh bmRvbSBibG9jayIgdG8gbWFwIGEgY29ycnVwdGVkIG9uZSBvbiBpdCwKPiA+IGl0IHRvdGFsbHkg ZGVmZWF0cyB0aGUgY3VycmVudCBiYWQgYmxvY2sgbW9kZWwgd2UgaGF2ZSBpbiBNVEQvVUJJCj4g PiBhbmQgc2ltcGx5IGNhbm5vdCBiZSBzdXBwb3J0ZWQgYXQgYWxsLiBKdXN0IHNraXBwaW5nIHRo ZQo+ID4gY3VycmVudGx5LXVzZWQtZm9yLUJNVCBibG9ja3Mgc291bmRzIGxpa2UgYSB2ZXJ5IGJh ZCBpZGVhIHRoYXQgd2lsbAo+ID4gYnJlYWsgeW91ciBzeXN0ZW0sIGxhdGVyLgo+ID4gIAo+IAo+ IFdlbGwgd2UgZGlzYWJsZSBpdCBhbmQgc2luY2UgaXQncyByZXNlcnZlZCwgZnJvbSB0aGUgc3lz dGVtIHNpZGUgeW91IGNhbgo+IGRvIGFsbCBraW5kIG9mIG1hZ2ljIHNpbmNlIHRoZSBzcGFjZSB1 c2VkIGZvciB0aGUgZHJpdmVyIGlzIG5vdAo+IGF2YWlsYWJsZSB0byB0aGUgc3lzdGVtIGJ1dCBJ IHdpbGwgdHJ5IHRvIGdhdGhlciBtb3JlIGluZm8gYWJvdXQgdGhpcyBpbgo+IHRoZSBuZXh0IGZl dyBkYXlzLgoKSSB1bmRlcnN0YW5kLCBidXQgaWYgeW91IGNhbm5vdCBnZXQgcmlkIG9mIGl0LCBp dCBtZWFucyAic29tZW9uZSIgaXMKdXNpbmcgaXQsIHByZXN1bWFibHkgdGhlIGJvb3Rsb2FkZXIs IHJpZ2h0PyBIb3cgY2FuIHRoZSBib290bG9hZGVyIHVzZQp0aGlzIGZlYXR1cmU/CgpPciBtYXli ZSB5b3UgbmVlZCB0aGlzIHRhYmxlIHRvIHNob3cgdGhlICh2ZW5kb3IpIGJvb3Rsb2FkZXIgIm5v dGhpbmcKY2hhbmdlZCwgdXNlIFBFQiBub3JtYWxseSwgbm9uZSBvZiB0aGVtIGlzIGJhZCwgdGhl cmUgaXMgbm8gb25nb2luZwpyZW1hcHBpbmciPwoKSW4gdGhpcyBjYXNlIEkgZ3Vlc3MgdGhlIHNp emUgb2YgdGhlIHRhYmxlIGlzIGEgbGluZWFyIGZ1bmN0aW9uIGFnYWluc3QKdGhlIHNpemUgb2Yg dGhlIGNoaXAgYW5kIHRodXMgY2FuIGJlIHN0YXRpY2FsbHkgZGVyaXZlZD8KClRoYW5rcywKTWlx dcOobAoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fCkxpbnV4IE1URCBkaXNjdXNzaW9uIG1haWxpbmcgbGlzdApodHRwOi8vbGlzdHMuaW5mcmFk ZWFkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LW10ZC8K From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from relay1-d.mail.gandi.net (relay1-d.mail.gandi.net [217.70.183.193]) (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 D6306204F74; Wed, 16 Oct 2024 08:58:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.70.183.193 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1729069113; cv=none; b=JquORrF0gUJt8n0I81wLeCT/R7uqWPYYkmfq+Qu5aS1zjvvfDx+TzgaUId81eYRWQ+5R0altP67dWdhrsZ68qR/oDimo8cvnUmkoPDGWS20PsE4ut3pBvCWtHY7RN4MDc7U/1kw+VwUcJq3+jNLJjk8uIpykY6okrt8DFAfIRbk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1729069113; c=relaxed/simple; bh=GiMJprnXspvPV/ACpRlvXGDB0qHzjjI6ZCKEXGqE6IU=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=bl4nVPqqhcOfSM8X7U50apGUrfonNapDT3awc10NrZ0n8BTAjsJnnq3VMPKdXXTONKK8q3TOBLyPSQFM+efrZweky8XqBlVUGffTgclZ2Cre688/r+v/G/dUdVMqJd5zAxb5ZFwttWpiOXN1Bqr+puAhL05QF052RvyWhl+DqJ4= 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=CrynI8QC; arc=none smtp.client-ip=217.70.183.193 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="CrynI8QC" Received: by mail.gandi.net (Postfix) with ESMTPSA id C8FAE240008; Wed, 16 Oct 2024 08:58:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1729069109; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=x3U/ETveGyfKnjLcVyYOTm+ngXWvKY86THZrnq130qU=; b=CrynI8QCFY+rV6CUfg7oqNg5Cn+axWaZvu7why2KR7lINNVmbCFmYzoaV/z7/evseoEgkG CMupTxXlD0rF9cm6UkwEwGYZRoofd7GLOm9aSc5zQdX7l7EK0mIPk1p0m2slbJi/kitpY2 r5irEDbDgCDXsmVvpMqVen3IBSKf93tn7szEEkbY8UKTnsUxBAEmQHLnJTjzz1fpjbkPVk 9eOGicU+Yfa6iKRHmzRbfxJ85A8E4jvjqHOrDMeGzuFTcaAJR6SC5DoCwlopXjcilEjSXL iowz7wqk8gWADsiWx5xhNSc2wthSPU3G6hjJlfOFOZEsucpUbduPKlgPlY81yg== Date: Wed, 16 Oct 2024 10:58:27 +0200 From: Miquel Raynal To: Christian Marangi Cc: Richard Weinberger , Vignesh Raghavendra , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Saravana Kannan , Florian Fainelli , Thomas Bogendoerfer , Wolfram Sang , linux-mtd@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Lorenzo Bianconi , upstream@airoha.com Subject: Re: [PATCH 2/3] dt-bindings: mtd: Add Documentation for Airoha fixed-partitions Message-ID: <20241016105827.22a6bb45@xps-13> In-Reply-To: <670f6c5e.170a0220.373da5.7bb7@mx.google.com> References: <20240925101422.8373-3-ansuelsmth@gmail.com> <20240925133003.619c40c4@xps-13> <66f3f58e.5d0a0220.5d655.b48a@mx.google.com> <20240925135256.32d3a0f7@xps-13> <66f3fcb7.5d0a0220.3ca4c2.ba83@mx.google.com> <20240930114819.609f9341@xps-13> <66fa7915.050a0220.1da288.aeca@mx.google.com> <20241001104225.67483dab@xps-13> <66fbcee8.df0a0220.2ad0cb.4f6a@mx.google.com> <20241002100006.5995fd10@xps-13> <670f6c5e.170a0220.373da5.7bb7@mx.google.com> Organization: Bootlin X-Mailer: Claws Mail 4.2.0 (GTK 3.24.41; x86_64-pc-linux-gnu) 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-GND-Sasl: miquel.raynal@bootlin.com Hi Christian, ansuelsmth@gmail.com wrote on Wed, 16 Oct 2024 09:33:46 +0200: > On Wed, Oct 02, 2024 at 10:00:06AM +0200, Miquel Raynal wrote: > > Hi Christian, > > =20 > > > > > > > Ok probably the description isn't clear enough. The missing i= nfo that > > > > > > > require this parser is the flash end. > > > > > > >=20 > > > > > > > Following the example we know the size of rootfs_data and sta= rt offset > > > > > > > AND we know the size of the ART partition. > > > > > > >=20 > > > > > > > There might be a space in the middle unused between the rootf= s_data > > > > > > > partition and the art partition. What is derived is the start= ing offset > > > > > > > of the art partition that is flash end - art partition size. > > > > > > > (where flash end change and is not always the same due to how= the special > > > > > > > bad block managament table reserved space is handled) > > > > > > >=20 > > > > > > > This is why 0xffffffff, used as a dummy offset to signal it w= ill be parsed at > > > > > > > runtime. On second tought tho maybe using this dummy offset i= s wrong and > > > > > > > I should just have something like > > > > > > >=20 > > > > > > > length =3D <0x300000>; > > > > > > >=20 > > > > > > > Is it clear now? Sorry for any confusion. =20 > > > > > >=20 > > > > > > I'm sorry but not really. You know the end of the physical devi= ce and > > > > > > the size of the ART partition, so you must know its start as we= ll? > > > > > > =20 > > > > >=20 > > > > > Before the system boot we know: > > > > > - size of the ART partition > > > > > - real size of the physical device (512mb... 1G... 64mb...) > > > > >=20 > > > > > When the physical device is probed (nand) a special driver is loa= ded > > > > > (before mtd parsing logic) that change the physical size of the d= evice > > > > > (mtd->size) as at the end of the nand some space is reserved for = bad > > > > > block management and other metadata info. =20 > > > >=20 > > > > Here you are explaining what you intend Linux to do, right? I would > > > > like to understand what you are trying to solve. I dont understand = why > > > > you need the size change, I don't understand why you don't know the > > > > start of the ART partition, I don't understand what the data you are > > > > hiding contains and who uses it :-) I'm sorry, this is too unclear = yet. =20 > > >=20 > > > Totally not a problem and thanks a lot for you keep asking them... Mo= re > > > than happy to clear things, I'm trying to solve a problem present on > > > Airoha SoC and upstreaming a correct parser for it. > > >=20 > > > What I'm trying to solve: > > >=20 > > > Correct access to this partition at the end of the flash in an automa= ted > > > way. > > >=20 > > > The content of this partition is the usual ART partition found on lot= s of > > > embedded devices. MAC address, wifi calibration data, serial. Usage is > > > NVMEM cells and userspace with dd command to extract data from. > > >=20 > > > Airoha use something also used by some mediatek SoC. They call it BMT > > > and it's currently used downstream in OpenWrt and they firmware. This= is > > > also used in the bootloader. > > >=20 > > > The usage of BMT is a custom way to handle bad blocks entirely by > > > software. At the end of the flash some space is reserved where info > > > about all the blocks of the flash are put. I'm not 100% sure about the > > > functionality of this but it can relocate block and do magic things to > > > handle bad blocks. For the scope of this change, the important info is > > > that after the BMT is probed, the operation of "reserving space" is d= one > > > by reducing the MTD flash size. So from the MTD subsystem, it does se= e a > > > smaller flash than it actually is. > > >=20 > > > The reserved space change! Across SoC or even devices but the BMT is a > > > must where it's used as bootloader makes use of it and writing to it > > > might confuse the bootloader corrupting data. (one block might be > > > flagged as bad ad data moved, BMT driver validates his table and do > > > operation) =20 > >=20 > > Ok, I think that's way clearer now. > > =20 >=20 > Hi sorry for the delay, very happy this is better now. >=20 > > So the BMT driver does not exist in mainline Linux, but you would like > > to skip this part of the MTD device to avoid smashing it. And it is in > > use by the vendor Bootloader I guess? =20 >=20 > Yes correct, idea is to permit easier access to the partition. I hope > (and assume) this driver will come upstream. >=20 > >=20 > > Is it some kind of table that is written by the chip itself in order to > > maintain a list of auto-replacement blocks for bad blocks? Can the size > > of this table move with the use of the device? (if yes, it's > > problematic, we don't want to resize MTD partitions without noticing, > > it would break eg. UBI). > > =20 >=20 > No chip hw bad block is disabled with this implementation and the table > size doesn't move/change so MTD partitions will stay at the same offset > after the first parse on boot. >=20 > > I believe this BMT block is going against the bad block handling in > > Linux, so I really wonder how one can use both mechanisms in a system. > > If the BMT layer takes "one random block" to map a corrupted one on it, > > it totally defeats the current bad block model we have in MTD/UBI > > and simply cannot be supported at all. Just skipping the > > currently-used-for-BMT blocks sounds like a very bad idea that will > > break your system, later. > > =20 >=20 > Well we disable it and since it's reserved, from the system side you can > do all kind of magic since the space used for the driver is not > available to the system but I will try to gather more info about this in > the next few days. I understand, but if you cannot get rid of it, it means "someone" is using it, presumably the bootloader, right? How can the bootloader use this feature? Or maybe you need this table to show the (vendor) bootloader "nothing changed, use PEB normally, none of them is bad, there is no ongoing remapping"? In this case I guess the size of the table is a linear function against the size of the chip and thus can be statically derived? Thanks, Miqu=C3=A8l