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: <CAMuHMdXA4-BZpvtCM8_9fYWLzoVsuCXDqvF3G4cVd50Cqsfv0g@mail.gmail.com>
Date:	Mon, 14 Dec 2015 11:22:46 +0100
From:	Geert Uytterhoeven <geert@...ux-m68k.org>
To:	David Gibson <david@...son.dropbear.id.au>
Cc:	Brian Norris <computersforpeace@...il.com>,
	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 Sat, Dec 12, 2015 at 6:51 AM, David Gibson
<david@...son.dropbear.id.au> 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 <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?
>
> 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@...x {
                        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@...ux-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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/