From: Miquel Raynal <miquel.raynal@bootlin.com> To: Rob Herring <robh@kernel.org> Cc: Richard Weinberger <richard@nod.at>, Vignesh Raghavendra <vigneshr@ti.com>, Tudor Ambarus <Tudor.Ambarus@microchip.com>, Pratyush Yadav <p.yadav@ti.com>, Michael Walle <michael@walle.cc>, linux-mtd@lists.infradead.org, Michal Simek <monstr@monstr.eu>, Thomas Petazzoni <thomas.petazzoni@bootlin.com>, devicetree@vger.kernel.org, Mark Brown <broonie@kernel.org>, linux-spi@vger.kernel.org Subject: Re: [PATCH v4 2/3] spi: dt-bindings: Describe stacked/parallel memories modes Date: Wed, 26 Jan 2022 12:18:55 +0100 [thread overview] Message-ID: <20220126121855.1139be2d@xps13> (raw) In-Reply-To: <CAL_Jsq+1X1V8UUHgfKaSbhZLtche3bqnCj62jFRVWzQLEc3hng@mail.gmail.com> Hi Rob, > > 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. > > Yeah, that's well reasoned and I agree. The other array case is you > have N values where each value represents different data rather than > instances of the same data. The challenge is for the schema fixups to > recognize which is which without saying the schema must look like > exactly X or Y as there will be exceptions. Ok, now I see the problem on the tooling side and why you chose not to use this syntax. > > I realized that the following example, which I was expecting to work, > > was failing: > > > > bindings: $ref: /schemas/types.yaml#/definitions/uint64-array > > dt: <property> = <uint64>, <uint64>; > > > > 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: <property> = <uint64 uint64>; > > > > But more disturbing, all the following constructions worked, when using > > 32-bits values instead: > > > > bindings: $ref: /schemas/types.yaml#/definitions/uint32-array > > dt: <property> = <uint32 uint32>; > > > > bindings: $ref: /schemas/types.yaml#/definitions/uint32-array > > dt: <property> = <uint32>, <uint32>; > > > > bindings: $ref: /schemas/types.yaml#/definitions/uint32-matrix > > dt: <property> = <uint32 uint32>; > > > > bindings: $ref: /schemas/types.yaml#/definitions/uint32-matrix > > dt: <property> = <uint32>, <uint32>; > > That works because there's some really ugly code to transform the > schema into both forms. Good to know, this kind of puzzled me when I tried all the configurations :) > > 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: <property> = <uint64 uint64>; > > Because of the /bits/ issue, yes. > > More importantly, the bracketing in dts files is not going to matter > soon (from a validation perspective). I'm working on moving validation > from using the yaml encoded DT (which depends on and preserves > brackets) to using dtbs. This will use the schemas to decode the > property values into the right format/type. Ok. Well, thanks for the feedback, with the latest dt-schema the tooling now validates the binding so I am going to send it as a v6 to collect your Ack. Thanks, Miquèl
WARNING: multiple messages have this Message-ID (diff)
From: Miquel Raynal <miquel.raynal@bootlin.com> To: Rob Herring <robh@kernel.org> Cc: Richard Weinberger <richard@nod.at>, Vignesh Raghavendra <vigneshr@ti.com>, Tudor Ambarus <Tudor.Ambarus@microchip.com>, Pratyush Yadav <p.yadav@ti.com>, Michael Walle <michael@walle.cc>, linux-mtd@lists.infradead.org, Michal Simek <monstr@monstr.eu>, Thomas Petazzoni <thomas.petazzoni@bootlin.com>, devicetree@vger.kernel.org, Mark Brown <broonie@kernel.org>, linux-spi@vger.kernel.org Subject: Re: [PATCH v4 2/3] spi: dt-bindings: Describe stacked/parallel memories modes Date: Wed, 26 Jan 2022 12:18:55 +0100 [thread overview] Message-ID: <20220126121855.1139be2d@xps13> (raw) In-Reply-To: <CAL_Jsq+1X1V8UUHgfKaSbhZLtche3bqnCj62jFRVWzQLEc3hng@mail.gmail.com> Hi Rob, > > 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. > > Yeah, that's well reasoned and I agree. The other array case is you > have N values where each value represents different data rather than > instances of the same data. The challenge is for the schema fixups to > recognize which is which without saying the schema must look like > exactly X or Y as there will be exceptions. Ok, now I see the problem on the tooling side and why you chose not to use this syntax. > > I realized that the following example, which I was expecting to work, > > was failing: > > > > bindings: $ref: /schemas/types.yaml#/definitions/uint64-array > > dt: <property> = <uint64>, <uint64>; > > > > 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: <property> = <uint64 uint64>; > > > > But more disturbing, all the following constructions worked, when using > > 32-bits values instead: > > > > bindings: $ref: /schemas/types.yaml#/definitions/uint32-array > > dt: <property> = <uint32 uint32>; > > > > bindings: $ref: /schemas/types.yaml#/definitions/uint32-array > > dt: <property> = <uint32>, <uint32>; > > > > bindings: $ref: /schemas/types.yaml#/definitions/uint32-matrix > > dt: <property> = <uint32 uint32>; > > > > bindings: $ref: /schemas/types.yaml#/definitions/uint32-matrix > > dt: <property> = <uint32>, <uint32>; > > That works because there's some really ugly code to transform the > schema into both forms. Good to know, this kind of puzzled me when I tried all the configurations :) > > 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: <property> = <uint64 uint64>; > > Because of the /bits/ issue, yes. > > More importantly, the bracketing in dts files is not going to matter > soon (from a validation perspective). I'm working on moving validation > from using the yaml encoded DT (which depends on and preserves > brackets) to using dtbs. This will use the schemas to decode the > property values into the right format/type. Ok. Well, thanks for the feedback, with the latest dt-schema the tooling now validates the binding so I am going to send it as a v6 to collect your Ack. Thanks, Miquèl ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2022-01-26 11:19 UTC|newest] Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-12-10 20:10 [PATCH v4 0/3] Stacked/parallel memories bindings Miquel Raynal 2021-12-10 20:10 ` Miquel Raynal 2021-12-10 20:10 ` [PATCH v4 1/3] dt-bindings: mtd: spi-nor: Allow two CS per device Miquel Raynal 2021-12-10 20:10 ` Miquel Raynal 2021-12-10 20:10 ` [PATCH v4 2/3] spi: dt-bindings: Describe stacked/parallel memories modes Miquel Raynal 2021-12-10 20:10 ` Miquel Raynal 2021-12-14 17:32 ` Rob Herring 2021-12-14 17:32 ` Rob Herring 2021-12-16 15:02 ` Miquel Raynal 2021-12-16 15:02 ` Miquel Raynal 2022-01-10 8:31 ` Miquel Raynal 2022-01-10 8:31 ` Miquel Raynal 2022-01-21 15:54 ` Rob Herring 2022-01-21 15:54 ` Rob Herring 2022-01-26 11:18 ` Miquel Raynal [this message] 2022-01-26 11:18 ` Miquel Raynal 2021-12-14 19:44 ` Pratyush Yadav 2021-12-14 19:44 ` Pratyush Yadav 2021-12-16 16:25 ` Miquel Raynal 2021-12-16 16:25 ` Miquel Raynal 2021-12-17 12:39 ` Pratyush Yadav 2021-12-17 12:39 ` Pratyush Yadav 2021-12-17 12:58 ` Miquel Raynal 2021-12-17 12:58 ` Miquel Raynal 2021-12-10 20:10 ` [PATCH v4 3/3] spi: dt-bindings: Add an example with two stacked flashes Miquel Raynal 2021-12-10 20:10 ` Miquel Raynal 2021-12-14 17:37 ` Rob Herring 2021-12-14 17:37 ` Rob Herring
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20220126121855.1139be2d@xps13 \ --to=miquel.raynal@bootlin.com \ --cc=Tudor.Ambarus@microchip.com \ --cc=broonie@kernel.org \ --cc=devicetree@vger.kernel.org \ --cc=linux-mtd@lists.infradead.org \ --cc=linux-spi@vger.kernel.org \ --cc=michael@walle.cc \ --cc=monstr@monstr.eu \ --cc=p.yadav@ti.com \ --cc=richard@nod.at \ --cc=robh@kernel.org \ --cc=thomas.petazzoni@bootlin.com \ --cc=vigneshr@ti.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.