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 B6C64C433F5 for ; Mon, 10 Jan 2022 08:32:21 +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=38rsopbcYvVWGgHOvipK6TBQWoM1s+daYbWIvTS1G5I=; b=K8w+M0JJAQao5f s6voDPUE3scSmKjYQywQsiXDKYnIcTk3WfbI5fXhiLSHszZWJ2oIVI6acMCM8GznJcFecHE4d9PtM Vlk0ujHYkG96lEOB4VHogzlkU9JjhYn6GCKgNK+NEEf0BxwM3m8bP9Jfets06z/g76ni57uhDc0aS +9mcpmAgbVe8Cq373aQU0Euj1btWgWWf2XpDJTB0dn+atwCtzOFXTXdxIURxXFZsLsHWnsFqzZ3q7 TwhqxZs0ulujelb6kjg2RL4mugZcszgowOmHi/rQIfHe9ByCC2/c06lCHzckdoAU2X5qfaeqTLXtr ImyHxV/0aVwRTvAtTdHw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1n6q5b-009t2j-9C; Mon, 10 Jan 2022 08:31:39 +0000 Received: from relay12.mail.gandi.net ([217.70.178.232]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1n6q5X-009t0B-B7 for linux-mtd@lists.infradead.org; Mon, 10 Jan 2022 08:31:37 +0000 Received: (Authenticated sender: miquel.raynal@bootlin.com) by relay12.mail.gandi.net (Postfix) with ESMTPSA id D2AF7200010; Mon, 10 Jan 2022 08:31:29 +0000 (UTC) Date: Mon, 10 Jan 2022 09:31:28 +0100 From: Miquel Raynal To: Rob Herring Cc: Richard Weinberger , Vignesh Raghavendra , Tudor Ambarus , Pratyush Yadav , Michael Walle , linux-mtd@lists.infradead.org, Michal Simek , Thomas Petazzoni , devicetree@vger.kernel.org, Mark Brown , linux-spi@vger.kernel.org Subject: Re: [PATCH v4 2/3] spi: dt-bindings: Describe stacked/parallel memories modes Message-ID: <20220110093128.2777152e@xps13> In-Reply-To: <20211216160226.4fac5ccc@xps13> References: <20211210201039.729961-1-miquel.raynal@bootlin.com> <20211210201039.729961-3-miquel.raynal@bootlin.com> <20211216160226.4fac5ccc@xps13> Organization: Bootlin X-Mailer: Claws Mail 3.17.7 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220110_003135_691680_2285138B X-CRM114-Status: GOOD ( 37.24 ) 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 SGkgUm9iLAoKbWlxdWVsLnJheW5hbEBib290bGluLmNvbSB3cm90ZSBvbiBUaHUsIDE2IERlYyAy MDIxIDE2OjAyOjI2ICswMTAwOgoKPiBIaSBSb2IsCj4gCj4gcm9iaEBrZXJuZWwub3JnIHdyb3Rl IG9uIFR1ZSwgMTQgRGVjIDIwMjEgMTE6MzI6NTYgLTA2MDA6Cj4gCj4gPiBPbiBGcmksIERlYyAx MCwgMjAyMSBhdCAwOToxMDozOFBNICswMTAwLCBNaXF1ZWwgUmF5bmFsIHdyb3RlOiAgCj4gPiA+ IERlc2NyaWJlIHR3byBuZXcgbWVtb3JpZXMgbW9kZXM6Cj4gPiA+IC0gQSBzdGFja2VkIG1vZGUg d2hlbiB0aGUgYnVzIGlzIGNvbW1vbiBidXQgdGhlIGFkZHJlc3Mgc3BhY2UgZXh0ZW5kZWQKPiA+ ID4gICB3aXRoIGFuIGFkZGl0aW5hbHMgd2lyZXMuCj4gPiA+IC0gQSBwYXJhbGxlbCBtb2RlIHdp dGggcGFyYWxsZWwgYnVzc2VzIGFjY2Vzc2luZyBwYXJhbGxlbCBmbGFzaGVzIHdoZXJlCj4gPiA+ ICAgdGhlIGRhdGEgaXMgc3ByZWFkLgo+ID4gPiAKPiA+ID4gU2lnbmVkLW9mZi1ieTogTWlxdWVs IFJheW5hbCA8bWlxdWVsLnJheW5hbEBib290bGluLmNvbT4KPiA+ID4gLS0tCj4gPiA+ICAuLi4v YmluZGluZ3Mvc3BpL3NwaS1wZXJpcGhlcmFsLXByb3BzLnlhbWwgICAgfCAyOSArKysrKysrKysr KysrKysrKysrCj4gPiA+ICAxIGZpbGUgY2hhbmdlZCwgMjkgaW5zZXJ0aW9ucygrKQo+ID4gPiAK PiA+ID4gZGlmZiAtLWdpdCBhL0RvY3VtZW50YXRpb24vZGV2aWNldHJlZS9iaW5kaW5ncy9zcGkv c3BpLXBlcmlwaGVyYWwtcHJvcHMueWFtbCBiL0RvY3VtZW50YXRpb24vZGV2aWNldHJlZS9iaW5k aW5ncy9zcGkvc3BpLXBlcmlwaGVyYWwtcHJvcHMueWFtbAo+ID4gPiBpbmRleCA1ZGQyMDkyMDZl ODguLjQxOTRmZWU4ZjU1NiAxMDA2NDQKPiA+ID4gLS0tIGEvRG9jdW1lbnRhdGlvbi9kZXZpY2V0 cmVlL2JpbmRpbmdzL3NwaS9zcGktcGVyaXBoZXJhbC1wcm9wcy55YW1sCj4gPiA+ICsrKyBiL0Rv Y3VtZW50YXRpb24vZGV2aWNldHJlZS9iaW5kaW5ncy9zcGkvc3BpLXBlcmlwaGVyYWwtcHJvcHMu eWFtbAo+ID4gPiBAQCAtODIsNiArODIsMzUgQEAgcHJvcGVydGllczoKPiA+ID4gICAgICBkZXNj cmlwdGlvbjoKPiA+ID4gICAgICAgIERlbGF5LCBpbiBtaWNyb3NlY29uZHMsIGFmdGVyIGEgd3Jp dGUgdHJhbnNmZXIuCj4gPiA+ICAKPiA+ID4gKyAgc3RhY2tlZC1tZW1vcmllczoKPiA+ID4gKyAg ICAkcmVmOiAvc2NoZW1hcy90eXBlcy55YW1sIy9kZWZpbml0aW9ucy91aW50NjQtbWF0cml4ICAg IAo+ID4gCj4gPiBtYXRyaXggb3IuLi4KPiA+ICAgCj4gPiA+ICsgICAgZGVzY3JpcHRpb246IFNl dmVyYWwgU1BJIG1lbW9yaWVzIGNhbiBiZSB3aXJlZCBpbiBzdGFja2VkIG1vZGUuCj4gPiA+ICsg ICAgICBUaGlzIGJhc2ljYWxseSBtZWFucyB0aGF0IGVpdGhlciBhIGRldmljZSBmZWF0dXJlcyBz ZXZlcmFsIGNoaXAKPiA+ID4gKyAgICAgIHNlbGVjdHMsIG9yIHRoYXQgZGlmZmVyZW50IGRldmlj ZXMgbXVzdCBiZSBzZWVuIGFzIGEgc2luZ2xlCj4gPiA+ICsgICAgICBiaWdnZXIgY2hpcC4gVGhp cyBiYXNpY2FsbHkgZG91YmxlcyAob3IgbW9yZSkgdGhlIHRvdGFsIGFkZHJlc3MKPiA+ID4gKyAg ICAgIHNwYWNlIHdpdGggb25seSBhIHNpbmdsZSBhZGRpdGlvbmFsIHdpcmUsIHdoaWxlIHN0aWxs IG5lZWRpbmcKPiA+ID4gKyAgICAgIHRvIHJlcGVhdCB0aGUgY29tbWFuZHMgd2hlbiBjcm9zc2lu ZyBhIGNoaXAgYm91bmRhcnkuIFRoZSBzaXplIG9mCj4gPiA+ICsgICAgICBlYWNoIGNoaXAgc2hv dWxkIGJlIHByb3ZpZGVkIGFzIG1lbWJlcnMgb2YgdGhlIGFycmF5LiAgICAKPiA+IAo+ID4gYXJy YXk/Cj4gPiAKPiA+IFNvdW5kcyBsaWtlIGFuIGFycmF5IGZyb20gdGhlIGRlc2NyaXB0aW9uIGFz IHRoZXJlIGlzIG9ubHkgMSBlbGVtZW50LCAKPiA+IHRoZSBzaXplLiAgCj4gCj4gV2VsbCwgd2hh dCBJIGV4cGVjdGVkIHRvIGhhdmUgd2FzIHNvbWV0aGluZyBsaWtlOgo+IAo+IGR0OgkJPHByb3Bl cnR5PiA9IDx1aW50NjQ+LCA8dWludDY0PjsKPiAKPiBJdCBzZWVtZWQgbGlrZSB0aGUgb25seSBw b3NzaWJsZSB3YXkgKHRoYXQgdGhlIHRvb2xpbmcgd291bGQgdmFsaWRhdGUpCj4gd2FzIHRvIHVz ZToKPiAKPiBiaW5kaW5nczoJJHJlZjogL3NjaGVtYXMvdHlwZXMueWFtbCMvZGVmaW5pdGlvbnMv dWludDY0LW1hdHJpeAo+IAo+IFNvIEkgYXNzdW1lZCBJIHdhcyBkZWZpbmluZyBhIG1hdHJpeCBv ZiBBeEIgZWxlbWVudHMsIHdoZXJlIEEgaXMgdGhlCj4gbnVtYmVyIG9mIGRldmljZXMgSSB3YW50 IHRvICJzdGFjayIgYW5kIEIgaXMgdGhlIG51bWJlciBvZiB2YWx1ZXMKPiBuZWVkZWQgdG8gZGVz Y3JpYmUgaXRzIHNpemUsIHNvIDEuCj4gCj4gSSByZWFsaXplZCB0aGF0IHRoZSBmb2xsb3dpbmcg ZXhhbXBsZSwgd2hpY2ggSSB3YXMgZXhwZWN0aW5nIHRvIHdvcmssCj4gd2FzIGZhaWxpbmc6Cj4g Cj4gYmluZGluZ3M6CSRyZWY6IC9zY2hlbWFzL3R5cGVzLnlhbWwjL2RlZmluaXRpb25zL3VpbnQ2 NC1hcnJheQo+IGR0OgkJPHByb3BlcnR5PiA9IDx1aW50NjQ+LCA8dWludDY0PjsKPiAKPiBJbmRl ZWQsIGFzIHlvdSBwcm9wb3NlLCB0aGlzIGFjdHVhbGx5IHdvcmtzIGJ1dCBkZXNjcmliZXMgdHdv IHZhbHVlcwo+ICh0aWVkIHNvbWVob3cpIGludG8gYSBzaW5nbGUgZWxlbWVudCwgd2hpY2ggaXMg bm90IGV4YWN0bHkgd2hhdCBJCj4gd2FudGVkOgo+IAo+IGJpbmRpbmdzOiAJJHJlZjogL3NjaGVt YXMvdHlwZXMueWFtbCMvZGVmaW5pdGlvbnMvdWludDY0LWFycmF5Cj4gZHQ6CQk8cHJvcGVydHk+ ID0gPHVpbnQ2NCB1aW50NjQ+Owo+IAo+IEJ1dCBtb3JlIGRpc3R1cmJpbmcsIGFsbCB0aGUgZm9s bG93aW5nIGNvbnN0cnVjdGlvbnMgd29ya2VkLCB3aGVuIHVzaW5nCj4gMzItYml0cyB2YWx1ZXMg aW5zdGVhZDoKPiAKPiBiaW5kaW5nczogCSRyZWY6IC9zY2hlbWFzL3R5cGVzLnlhbWwjL2RlZmlu aXRpb25zL3VpbnQzMi1hcnJheQo+IGR0OgkJPHByb3BlcnR5PiA9IDx1aW50MzIgdWludDMyPjsK PiAKPiBiaW5kaW5nczogCSRyZWY6IC9zY2hlbWFzL3R5cGVzLnlhbWwjL2RlZmluaXRpb25zL3Vp bnQzMi1hcnJheQo+IGR0OgkJPHByb3BlcnR5PiA9IDx1aW50MzI+LCA8dWludDMyPjsKPiAKPiBi aW5kaW5nczogCSRyZWY6IC9zY2hlbWFzL3R5cGVzLnlhbWwjL2RlZmluaXRpb25zL3VpbnQzMi1t YXRyaXgKPiBkdDoJCTxwcm9wZXJ0eT4gPSA8dWludDMyIHVpbnQzMj47Cj4gCj4gYmluZGluZ3M6 IAkkcmVmOiAvc2NoZW1hcy90eXBlcy55YW1sIy9kZWZpbml0aW9ucy91aW50MzItbWF0cml4Cj4g ZHQ6CQk8cHJvcGVydHk+ID0gPHVpbnQzMj4sIDx1aW50MzI+Owo+IAo+IEkgYW0gZmluZSB3YWl0 aW5nIGEgYml0IGlmIHlvdSB0aGluayB0aGVyZSBpcyBhIG5lZWQgZm9yIHNvbWUgdG9vbGluZwo+ IHVwZGF0ZSBvbiB5b3VyIHNpZGUuIE90aGVyd2lzZSwgZG8geW91IHJlYWxseSB0aGluayB0aGF0 IHRoaXMgc29sdXRpb24KPiBpcyB0aGUgb25lIHdlIHNob3VsZCByZWFsbHkgdXNlPwo+IAo+IGJp bmRpbmdzOiAJJHJlZjogL3NjaGVtYXMvdHlwZXMueWFtbCMvZGVmaW5pdGlvbnMvdWludDY0LWFy cmF5Cj4gZHQ6CQk8cHJvcGVydHk+ID0gPHVpbnQ2NCB1aW50NjQ+Owo+IAo+IEJlY2F1c2UgZnJv bSBteSBwb2ludCBvZiB2aWV3IGl0IGRvZXMgbm90IG1hdGNoIHdoYXQgd2UgdXN1YWxseSBkbyBm b3IKPiBvdGhlciAidHlwZXMiIG9mIGVsZW1lbnRzLCBzdWNoIGFzOgo+IAo+IGR0OgkJPHByb3Bl cnR5PiA9IDxwaGFuZGxlMSBpbmRleDE+LCA8cGhhbmRsZTIgaW5kZXgyPjsKPiAKPiBvcgo+IAo+ IGR0OgkJPHByb3BlcnR5PiA9IDxzbWFsbC12YWwxPiwgPHNtYWxsLXZhbDI+OwoKU29ycnkgZm9y IGJvdGhlcmluZyB5b3UsIGlzIHRoaXMgc29tZXRoaW5nIHlvdSBzdGlsbCBoYXZlIGluIG1pbmQ/ IEl0CnNlZW1zIHRoYXQgdGhlIHRvb2xpbmcgaXMgdGhlIGN1bHByaXQgaGVyZSBhbmQgSSB3b3Vs ZCBoaWdobHkKYXBwcmVjaWF0ZSB5b3VyIGhlbHAgb24gdGhhdCBwb2ludC4KClRoYW5rcywKTWlx dcOobAoKPiAKPiA+ICAgCj4gPiA+ICsgICAgbWluSXRlbXM6IDIKPiA+ID4gKyAgICBtYXhJdGVt czogMgo+ID4gPiArICAgIGl0ZW1zOgo+ID4gPiArICAgICAgbWF4SXRlbXM6IDEgICAgCj4gPiAK PiA+IFRoaXMgc2F5cyB5b3UgY2FuIG9ubHkgaGF2ZSAyIDY0LWJpdCBlbnRyaWVzLiBQcm9iYWJs eSBub3Qgd2hhdCB5b3UgCj4gPiB3YW50LiBUaGlzIGxvb2tzIGxpa2UgYSBjYXNlIGZvciBhIG1h eEl0ZW1zICdzaG91bGQgYmUgZW5vdWdoIGZvciBub3cnIAo+ID4gdHlwZSBvZiB2YWx1ZS4gIAo+ IAo+IFllcywgdGhhdCBpcyB3aGF0IEkgd2FudGVkIHRvIGRlc2NyaWJlLgo+IAo+IEluIG15IHJl Y2VudCBjb250cmlidXRpb25zIHlvdSBhbHdheXMgcHJlZmVycmVkIHRvIGJvdW5kIHRoaW5ncyBh cyBtdWNoCj4gYXMgcG9zc2libGUsIGV2ZW4gdGhvdWdoIGxhdGVyIGl0IG1pZ2h0IGJlY29tZSBu ZWNlc3NhcnkgdG8gbG9vc2VuIHRoZQo+IGNvbnN0cmFpbnQuIFJpZ2h0IG5vdyBJIHNlZSB0aGUg dXNlIG9mIHRoZXNlIHByb3BlcnRpZXMgZm9yIDIgZGV2aWNlcywKPiBidXQgaW4gdGhlb3J5IHRo ZXJlIGlzIG5vIGxpbWl0Lgo+IAo+IE9mIGNvdXJzZSBpZiB3ZSBzd2l0Y2ggdG8gdGhlIGFycmF5 IHJlcHJlc2VudGF0aW9uIEkgc3VwcG9zZSBJIHNob3VsZAo+IHN0aWNrIHRvOgo+IAo+ICsgICAg bWluSXRlbXM6IDIKPiArICAgIG1heEl0ZW1zOiAyCgpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KTGludXggTVREIGRpc2N1c3Npb24gbWFpbGlu ZyBsaXN0Cmh0dHA6Ly9saXN0cy5pbmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGluZm8vbGludXgt bXRkLwo= 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 E4FF8C433EF for ; Mon, 10 Jan 2022 08:33:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241056AbiAJIde convert rfc822-to-8bit (ORCPT ); Mon, 10 Jan 2022 03:33:34 -0500 Received: from relay12.mail.gandi.net ([217.70.178.232]:39889 "EHLO relay12.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240898AbiAJIbe (ORCPT ); Mon, 10 Jan 2022 03:31:34 -0500 Received: (Authenticated sender: miquel.raynal@bootlin.com) by relay12.mail.gandi.net (Postfix) with ESMTPSA id D2AF7200010; Mon, 10 Jan 2022 08:31:29 +0000 (UTC) Date: Mon, 10 Jan 2022 09:31:28 +0100 From: Miquel Raynal To: Rob Herring Cc: Richard Weinberger , Vignesh Raghavendra , Tudor Ambarus , Pratyush Yadav , Michael Walle , linux-mtd@lists.infradead.org, Michal Simek , Thomas Petazzoni , devicetree@vger.kernel.org, Mark Brown , linux-spi@vger.kernel.org Subject: Re: [PATCH v4 2/3] spi: dt-bindings: Describe stacked/parallel memories modes Message-ID: <20220110093128.2777152e@xps13> In-Reply-To: <20211216160226.4fac5ccc@xps13> References: <20211210201039.729961-1-miquel.raynal@bootlin.com> <20211210201039.729961-3-miquel.raynal@bootlin.com> <20211216160226.4fac5ccc@xps13> Organization: Bootlin X-Mailer: Claws Mail 3.17.7 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Precedence: bulk List-ID: X-Mailing-List: linux-spi@vger.kernel.org Hi Rob, miquel.raynal@bootlin.com wrote on Thu, 16 Dec 2021 16:02:26 +0100: > Hi Rob, > > robh@kernel.org wrote on Tue, 14 Dec 2021 11:32:56 -0600: > > > On Fri, Dec 10, 2021 at 09:10:38PM +0100, Miquel Raynal wrote: > > > Describe two new memories modes: > > > - A stacked mode when the bus is common but the address space extended > > > with an additinals wires. > > > - A parallel mode with parallel busses accessing parallel flashes where > > > the data is spread. > > > > > > Signed-off-by: Miquel Raynal > > > --- > > > .../bindings/spi/spi-peripheral-props.yaml | 29 +++++++++++++++++++ > > > 1 file changed, 29 insertions(+) > > > > > > diff --git a/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml b/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml > > > index 5dd209206e88..4194fee8f556 100644 > > > --- a/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml > > > +++ b/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml > > > @@ -82,6 +82,35 @@ properties: > > > description: > > > Delay, in microseconds, after a write transfer. > > > > > > + stacked-memories: > > > + $ref: /schemas/types.yaml#/definitions/uint64-matrix > > > > matrix or... > > > > > + description: Several SPI memories can be wired in stacked mode. > > > + This basically means that either a device features several chip > > > + selects, or that different devices must be seen as a single > > > + bigger chip. This basically doubles (or more) the total address > > > + space with only a single additional wire, while still needing > > > + to repeat the commands when crossing a chip boundary. The size of > > > + each chip should be provided as members of the array. > > > > array? > > > > Sounds like an array from the description as there is only 1 element, > > the size. > > Well, what I expected to have was something like: > > dt: = , ; > > It seemed like the only possible way (that the tooling would validate) > was to use: > > bindings: $ref: /schemas/types.yaml#/definitions/uint64-matrix > > So I assumed I was defining a matrix of AxB elements, where A is the > number of devices I want to "stack" and B is the number of values > needed to describe its size, so 1. > > I realized that the following example, which I was expecting to work, > was failing: > > bindings: $ref: /schemas/types.yaml#/definitions/uint64-array > dt: = , ; > > Indeed, as you propose, this actually works but describes two values > (tied somehow) into a single element, which is not exactly what I > wanted: > > bindings: $ref: /schemas/types.yaml#/definitions/uint64-array > dt: = ; > > But more disturbing, all the following constructions worked, when using > 32-bits values instead: > > bindings: $ref: /schemas/types.yaml#/definitions/uint32-array > dt: = ; > > bindings: $ref: /schemas/types.yaml#/definitions/uint32-array > dt: = , ; > > bindings: $ref: /schemas/types.yaml#/definitions/uint32-matrix > dt: = ; > > bindings: $ref: /schemas/types.yaml#/definitions/uint32-matrix > dt: = , ; > > I am fine waiting a bit if you think there is a need for some tooling > update on your side. Otherwise, do you really think that this solution > is the one we should really use? > > bindings: $ref: /schemas/types.yaml#/definitions/uint64-array > dt: = ; > > Because from my point of view it does not match what we usually do for > other "types" of elements, such as: > > dt: = , ; > > or > > dt: = , ; Sorry for bothering you, is this something you still have in mind? It seems that the tooling is the culprit here and I would highly appreciate your help on that point. Thanks, Miquèl > > > > > > + minItems: 2 > > > + maxItems: 2 > > > + items: > > > + maxItems: 1 > > > > This says you can only have 2 64-bit entries. Probably not what you > > want. This looks like a case for a maxItems 'should be enough for now' > > type of value. > > Yes, that is what I wanted to describe. > > In my recent contributions you always preferred to bound things as much > as possible, even though later it might become necessary to loosen the > constraint. Right now I see the use of these properties for 2 devices, > but in theory there is no limit. > > Of course if we switch to the array representation I suppose I should > stick to: > > + minItems: 2 > + maxItems: 2