Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932434AbbLNKWz (ORCPT ); Mon, 14 Dec 2015 05:22:55 -0500 Received: from mail-ob0-f177.google.com ([209.85.214.177]:36277 "EHLO mail-ob0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932165AbbLNKWs (ORCPT ); Mon, 14 Dec 2015 05:22:48 -0500 MIME-Version: 1.0 In-Reply-To: <20151212055105.GA17011@voom.fritz.box> References: <1449292763-129421-1-git-send-email-computersforpeace@gmail.com> <1449292763-129421-4-git-send-email-computersforpeace@gmail.com> <20151207013628.GC20139@voom.fritz.box> <20151210204324.GK144338@google.com> <20151212055105.GA17011@voom.fritz.box> Date: Mon, 14 Dec 2015 11:22:46 +0100 X-Google-Sender-Auth: 834fkfEFOTuettUxj_sMRmg0UBQ Message-ID: Subject: Re: [RFC PATCH 3/7] doc: dt: mtd: partition: add on-flash format binding From: Geert Uytterhoeven To: David Gibson Cc: Brian Norris , 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 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4396 Lines: 109 On Sat, Dec 12, 2015 at 6:51 AM, David Gibson wrote: > On Thu, Dec 10, 2015 at 12:43:24PM -0800, Brian Norris wrote: >> 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? > > Ah.. that is an excellent point, and leads me to realise that using > compatible in this way is wrong. The whole point of compatible is > that the node is, well, compatible with *all* the things in the list, > and therefore the things in the list are compatible with each other. > > Using it for a list of entirely different things to attempt in order > is not correct. Isn't the idea behind a partition table that all partition information is stored on the device in a well-known format, so you don't need additional properties? If the only property needed is the partition table offset, it can be encoded in the unit-address, and the "reg" property: partitions { partition-table@xxxx { reg = <0xxxx ...>; ... }; ... }; If you do need additional properties, you'll have to add separate partition table nodes. Where? Outside the "partitions" subnode? What with multiple partition tables - some needing properties (outside "partitions"), - others not (outside/inside "partitions"), - others needing the offset (inside "partitions"? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/