linux-kernel - Re: [RFC PATCH 3/7] doc: dt: mtd: partition: add on-flash format binding

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 10 Dec 2015 12:43:24 -0800
From:	Brian Norris <computersforpeace@...il.com>
To:	David Gibson <david@...son.dropbear.id.au>
Cc:	Michal Suchanek <hramrach@...il.com>,
	Jonas Gorski <jogo@...nwrt.org>,
	Boris Brezillon <boris.brezillon@...e-electrons.com>,
	Arnd Bergmann <arnd@...db.de>,
	Geert Uytterhoeven <geert+renesas@...der.be>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	devicetree-spec@...r.kernel.org, Simon Arlott <simon@...e.lp0.eu>,
	Linus Walleij <linus.walleij@...aro.org>,
	Rafał Miłecki <zajec5@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Jason Gunthorpe <jgunthorpe@...idianresearch.com>,
	Rob Herring <robh+dt@...nel.org>,
	MTD Maling List <linux-mtd@...ts.infradead.org>,
	Hauke Mehrtens <hauke@...ke-m.de>
Subject: Re: [RFC PATCH 3/7] doc: dt: mtd: partition: add on-flash format
 binding

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@...nwrt.org> wrote:
> > > On Sat, Dec 5, 2015 at 6:19 AM, Brian Norris
> > > <computersforpeace@...il.com> 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 linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/