All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org>
To: Geert Uytterhoeven <geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>
Cc: "Brian Norris"
	<computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	"Michal Suchanek"
	<hramrach-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	"Jonas Gorski" <jogo-p3rKhJxN3npAfugRpC6u6w@public.gmane.org>,
	"Boris Brezillon"
	<boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>,
	"Arnd Bergmann" <arnd-r2nGTMty4D4@public.gmane.org>,
	"Geert Uytterhoeven"
	<geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>,
	"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	devicetree-spec-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	"Simon Arlott" <simon-A6De1vDTPLDsq35pWSNszA@public.gmane.org>,
	"Linus Walleij"
	<linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	"Rafał Miłecki" <zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"Jason Gunthorpe"
	<jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>,
	"Rob Herring" <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	"MTD Maling List"
	<linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
	"Hauke Mehrtens" <hauke-5/S+JYg5SzeELgA04lAiVw@public.gmane.org>
Subject: Re: [RFC PATCH 3/7] doc: dt: mtd: partition: add on-flash format binding
Date: Tue, 15 Dec 2015 17:00:56 +1100	[thread overview]
Message-ID: <20151215060056.GB3011@voom.redhat.com> (raw)
In-Reply-To: <CAMuHMdXA4-BZpvtCM8_9fYWLzoVsuCXDqvF3G4cVd50Cqsfv0g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 4392 bytes --]

On Mon, Dec 14, 2015 at 11:22:46AM +0100, Geert Uytterhoeven wrote:
> On Sat, Dec 12, 2015 at 6:51 AM, David Gibson
> <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org> 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-p3rKhJxN3npAfugRpC6u6w@public.gmane.org> wrote:
> >> > > > On Sat, Dec 5, 2015 at 6:19 AM, Brian Norris
> >> > > > <computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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?

I guess that's the idea, but I wouldn't like to count on it.

And more importantly, it's still abusing the 'compatible' property.  A
node is supposed to be compatible with *everything* in 'compatible',
not just one of the things listed there.

> 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 ...>;
>                         ...
>                 };
> 
>                 ...
>         };

Urgh.. and that's abusing the unit address.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: David Gibson <david@gibson.dropbear.id.au>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: "Brian Norris" <computersforpeace@gmail.com>,
	"Michal Suchanek" <hramrach@gmail.com>,
	"Jonas Gorski" <jogo@openwrt.org>,
	"Boris Brezillon" <boris.brezillon@free-electrons.com>,
	"Arnd Bergmann" <arnd@arndb.de>,
	"Geert Uytterhoeven" <geert+renesas@glider.be>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	devicetree-spec@vger.kernel.org,
	"Simon Arlott" <simon@fire.lp0.eu>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Rafał Miłecki" <zajec5@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Jason Gunthorpe" <jgunthorpe@obsidianresearch.com>,
	"Rob Herring" <robh+dt@kernel.org>,
	"MTD Maling List" <linux-mtd@lists.infradead.org>,
	"Hauke Mehrtens" <hauke@hauke-m.de>
Subject: Re: [RFC PATCH 3/7] doc: dt: mtd: partition: add on-flash format binding
Date: Tue, 15 Dec 2015 17:00:56 +1100	[thread overview]
Message-ID: <20151215060056.GB3011@voom.redhat.com> (raw)
In-Reply-To: <CAMuHMdXA4-BZpvtCM8_9fYWLzoVsuCXDqvF3G4cVd50Cqsfv0g@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 4306 bytes --]

On Mon, Dec 14, 2015 at 11:22:46AM +0100, Geert Uytterhoeven wrote:
> On Sat, Dec 12, 2015 at 6:51 AM, David Gibson
> <david@gibson.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@openwrt.org> wrote:
> >> > > > On Sat, Dec 5, 2015 at 6:19 AM, Brian Norris
> >> > > > <computersforpeace@gmail.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?

I guess that's the idea, but I wouldn't like to count on it.

And more importantly, it's still abusing the 'compatible' property.  A
node is supposed to be compatible with *everything* in 'compatible',
not just one of the things listed there.

> 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 ...>;
>                         ...
>                 };
> 
>                 ...
>         };

Urgh.. and that's abusing the unit address.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  parent reply	other threads:[~2015-12-15  6:00 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-05  5:19 [RFC PATCH 0/7] mtd: partitions: add of_match_table support Brian Norris
2015-12-05  5:19 ` Brian Norris
2015-12-05  5:19 ` [RFC PATCH 1/7] mtd: move partition parsers to drivers/mtd/partitions/ Brian Norris
2015-12-05  5:19   ` Brian Norris
2015-12-05  5:19 ` [RFC PATCH 2/7] mtd: move partition parsers' Kconfig under a sub-menu Brian Norris
2015-12-05  5:19   ` Brian Norris
2015-12-05  5:19 ` [RFC PATCH 4/7] mtd: add of_match_mtd_parser() and of_mtd_match_mtd_parser() helpers Brian Norris
2015-12-05  5:19   ` Brian Norris
     [not found]   ` <1449292763-129421-5-git-send-email-computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-12-07  2:45     ` Rob Herring
2015-12-07  2:45       ` Rob Herring
     [not found]       ` <CAL_JsqLV1mDpW9tD0XjWRxZSSsYuDiqHbuADQmBUtACgYiHJ+w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-12-07 18:13         ` Brian Norris
2015-12-07 18:13           ` Brian Norris
     [not found]           ` <20151207181308.GN120110-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2015-12-07 19:00             ` Rob Herring
2015-12-07 19:00               ` Rob Herring
2015-12-05  5:19 ` [RFC PATCH 6/7] RFC: mtd: partitions: enable of_match_table matching Brian Norris
2015-12-05  5:19   ` Brian Norris
2015-12-05  5:19 ` [RFC PATCH 7/7] mtd: partitions: add Google's FMAP partition parser Brian Norris
2015-12-05  5:19   ` Brian Norris
2015-12-05  5:19   ` Brian Norris
     [not found] ` <1449292763-129421-1-git-send-email-computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-12-05  5:19   ` [RFC PATCH 3/7] doc: dt: mtd: partition: add on-flash format binding Brian Norris
2015-12-05  5:19     ` Brian Norris
     [not found]     ` <1449292763-129421-4-git-send-email-computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-12-05 11:39       ` Jonas Gorski
2015-12-05 11:39         ` Jonas Gorski
     [not found]         ` <CAOiHx=nz2bdA_R610ozsQHhccdcrHVVCamTtne5ReHrA-FcaaQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-12-05 21:33           ` Michal Suchanek
2015-12-05 21:33             ` Michal Suchanek
     [not found]             ` <CAOMqctTbUNd0GtY07YJuxem9HkU1WZ-NtO556=Yg2QrsF49Xjw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-12-07  1:36               ` David Gibson
2015-12-07  1:36                 ` David Gibson
     [not found]                 ` <20151207013628.GC20139-RXTfZT5YzpxwFLYp8hBm2A@public.gmane.org>
2015-12-10 20:43                   ` Brian Norris
2015-12-10 20:43                     ` Brian Norris
     [not found]                     ` <20151210204324.GK144338-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2015-12-11 15:58                       ` Michal Suchanek
2015-12-11 15:58                         ` Michal Suchanek
2015-12-12  5:51                     ` David Gibson
     [not found]                       ` <20151212055105.GA17011-RXTfZT5YzpxwFLYp8hBm2A@public.gmane.org>
2015-12-14 10:22                         ` Geert Uytterhoeven
2015-12-14 10:22                           ` Geert Uytterhoeven
     [not found]                           ` <CAMuHMdXA4-BZpvtCM8_9fYWLzoVsuCXDqvF3G4cVd50Cqsfv0g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-12-14 12:28                             ` Michal Suchanek
2015-12-14 12:28                               ` Michal Suchanek
2015-12-15  6:00                             ` David Gibson [this message]
2015-12-15  6:00                               ` David Gibson
     [not found]                               ` <20151215060056.GB3011-1s0os16eZneny3qCrzbmXA@public.gmane.org>
2015-12-15 10:03                                 ` Geert Uytterhoeven
2015-12-15 10:03                                   ` Geert Uytterhoeven
2015-12-17  1:05                                   ` David Gibson
2015-12-07  3:07       ` Rob Herring
2015-12-07  3:07         ` Rob Herring
2015-12-05  5:19   ` [RFC PATCH 5/7] mtd: partitions: factor out "match by name" handling Brian Norris
2015-12-05  5:19     ` Brian Norris
2015-12-05 10:15   ` [RFC PATCH 0/7] mtd: partitions: add of_match_table support Geert Uytterhoeven
2015-12-05 10:15     ` Geert Uytterhoeven
     [not found]     ` <CAMuHMdUJXHs_OhT0da+kzc=D4MOFUT9BB3eJ+7a_p6DYx-PKBA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-12-05 18:06       ` Michal Suchanek
2015-12-05 18:06         ` Michal Suchanek
2015-12-10 20:54       ` Brian Norris
2015-12-10 20:54         ` Brian Norris
     [not found]         ` <20151210205449.GL144338-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2015-12-11  8:44           ` Geert Uytterhoeven
2015-12-11  8:44             ` Geert Uytterhoeven
     [not found]             ` <CAMuHMdV-uethsChWVZGSx1JNcAofODmg14ppGYJP2ewfwhEv1Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-12-11 15:34               ` Michal Suchanek
2015-12-11 15:34                 ` Michal Suchanek
     [not found]                 ` <CAOMqctQVMCEa_k4xMW1qooEpe8X1-NhUOjD6pp0qJpDP_H+8hw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-12-11 16:00                   ` Geert Uytterhoeven
2015-12-11 16:00                     ` Geert Uytterhoeven
     [not found]                     ` <CAMuHMdV2feXKWkJzRkMUBiAUCxp4LwaRgg+aPYwm0sUnKzm0Rg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-12-11 16:18                       ` Michal Suchanek
2015-12-11 16:18                         ` Michal Suchanek
2015-12-12  1:33               ` Brian Norris
2015-12-12  1:33                 ` Brian Norris
     [not found]                 ` <20151212013349.GA86087-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2015-12-14 10:15                   ` Geert Uytterhoeven
2015-12-14 10:15                     ` Geert Uytterhoeven
2015-12-05 11:35 ` Jonas Gorski
     [not found]   ` <CAOiHx==8TFK9t4h2C0Q+j==nuRP3EbyVa+nuYuSEj_LCDa820Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-12-10 21:06     ` Brian Norris
2015-12-10 21:06       ` Brian Norris

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151215060056.GB3011@voom.redhat.com \
    --to=david-xt8fgy+axnrb3ne2bgzf6laj5h9x9tb+@public.gmane.org \
    --cc=arnd-r2nGTMty4D4@public.gmane.org \
    --cc=boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org \
    --cc=computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=devicetree-spec-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org \
    --cc=geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org \
    --cc=hauke-5/S+JYg5SzeELgA04lAiVw@public.gmane.org \
    --cc=hramrach-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org \
    --cc=jogo-p3rKhJxN3npAfugRpC6u6w@public.gmane.org \
    --cc=linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=simon-A6De1vDTPLDsq35pWSNszA@public.gmane.org \
    --cc=zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.