From mboxrd@z Thu Jan 1 00:00:00 1970 From: Brian Norris Subject: Re: [RFC PATCH 3/7] doc: dt: mtd: partition: add on-flash format binding Date: Thu, 10 Dec 2015 12:43:24 -0800 Message-ID: <20151210204324.GK144338@google.com> References: <1449292763-129421-1-git-send-email-computersforpeace@gmail.com> <1449292763-129421-4-git-send-email-computersforpeace@gmail.com> <20151207013628.GC20139@voom.fritz.box> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20151207013628.GC20139-RXTfZT5YzpxwFLYp8hBm2A@public.gmane.org> Sender: devicetree-spec-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: David Gibson Cc: Michal Suchanek , Jonas Gorski , Boris Brezillon , Arnd Bergmann , Geert Uytterhoeven , "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , devicetree-spec-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Simon Arlott , Linus Walleij , =?utf-8?B?UmFmYcWCIE1pxYJlY2tp?= , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Jason Gunthorpe , Rob Herring , MTD Maling List , Hauke Mehrtens List-Id: devicetree@vger.kernel.org On Mon, Dec 07, 2015 at 12:36:28PM +1100, David Gibson wrote: > On Sat, Dec 05, 2015 at 10:33:30PM +0100, Michal Suchanek wrote: > > On 5 December 2015 at 12:39, Jonas Gorski wrote: > > > On Sat, Dec 5, 2015 at 6:19 AM, Brian Norris > > > wrote: > > > > >> + > > >> +Examples: > > >> + > > >> +flash@0 { > > >> + partitions { > > >> + compatible = "google,fmap"; > > >> + }; > > >> +}; > > > > > > I wonder if this wouldn't be better served in a separate binding doc > > > with its compatible name as the filename, like we do with > > > driver^Whardware blocks, especially if we want to add more parsers. > > > > > > I find that *very* counter productive for bindings that go to the same > > node. You have a description of a node, and then suddenly there you > > have another file with another description of the same node. Totally > > awesome. > > I can't actually work out from that if you're agreeing with the > original post or the first reply. Perhaps I'm biased, but I think he was agreeing with the first reply. (Particularly, "I find that *very* counter productive" uses the word "that" to refer to "separate binding doc[s]".) > > Also how do you plan to write partitioning schemes with parameters > > like with non-zero offset of the partition table. If you are directing this question at me: I don't have a specific plan for it. MTD parsers don't currently take external input for this; many scan the whole device, but some might also have conventions built into the parser itself too, so this just gets hooked based on "compatible". But if the need arose, I would hope we could work out a common binding. > Presumably with properties in the patitions node. Not seeing the > problem here. I believe Michal is bringing up the (important, IMO) point that if distinct partition types are being described in the same node, then any use of additional properties *must* be closely coordinated. We can't have two parsers "foo" and "bar" defining conflicting uses of the same property in the same node, like this: partitions { compatible = "foo", "bar"; property-baz = ...; // e.g., reg = <...>; }; where if "foo" is not found, we fall back to "bar". But what if "foo" and "bar" use "property-baz" differently? Having everything in one doc would help ensure that the entire "partitions" binding is considered as a whole when extending it, in my (and an in my interpretation of Michal's) opinion. Brian