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]

Message-ID: <CAOMqctQyS0dTAn6nifNzTFTqAZ3caJTj=yKnawP-A3Z4=Sv5rw@mail.gmail.com>
Date:	Fri, 11 Dec 2015 16:58:00 +0100
From:	Michal Suchanek <hramrach@...il.com>
To:	Brian Norris <computersforpeace@...il.com>
Cc:	David Gibson <david@...son.dropbear.id.au>,
	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

Hello,

On 10 December 2015 at 21:43, Brian Norris <computersforpeace@...il.com> 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 <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]".)
>
>
> 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:
>

I have seen some MFD bindings which are described in multiple files
with no crossreference whatsoever.

If on-flash partition table bindings are going to be the same then
people are not going to find there are even some on-flash partition
table bindings (because the document describing the in-DT bindings is
complete and exhaustive, right). Can't even imagine coordination.

When you have to grep the tree for docs anyway what's even the point
of the Documentation directory?

You can just grep the whole tree.

Thanks

Michal
--
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/