From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753019AbbLJUnc (ORCPT ); Thu, 10 Dec 2015 15:43:32 -0500 Received: from mail-pa0-f44.google.com ([209.85.220.44]:36309 "EHLO mail-pa0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751143AbbLJUn3 (ORCPT ); Thu, 10 Dec 2015 15:43:29 -0500 Date: Thu, 10 Dec 2015 12:43:24 -0800 From: Brian Norris To: David Gibson Cc: Michal Suchanek , Jonas Gorski , Boris Brezillon , Arnd Bergmann , Geert Uytterhoeven , "devicetree@vger.kernel.org" , devicetree-spec@vger.kernel.org, Simon Arlott , Linus Walleij , =?utf-8?B?UmFmYcWCIE1pxYJlY2tp?= , "linux-kernel@vger.kernel.org" , Jason Gunthorpe , Rob Herring , MTD Maling List , Hauke Mehrtens Subject: Re: [RFC PATCH 3/7] doc: dt: mtd: partition: add on-flash format binding 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 Content-Disposition: inline In-Reply-To: <20151207013628.GC20139@voom.fritz.box> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@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