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 <jogo@xxxxxxxxxxx> wrote: > > > On Sat, Dec 5, 2015 at 6:19 AM, Brian Norris > > > <computersforpeace@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html