linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: computersforpeace@gmail.com (Brian Norris)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/3] mtd: create a partition type device tree binding
Date: Fri, 30 Oct 2015 10:51:45 -0700	[thread overview]
Message-ID: <20151030175145.GF13239@google.com> (raw)
In-Reply-To: <CACRpkdYS5Jf8UC2K0bNdEQZDjTeZZx44Uu-kkof+9E=4Ny0oDg@mail.gmail.com>

On Fri, Oct 30, 2015 at 03:00:57PM +0100, Linus Walleij wrote:
> On Thu, Oct 29, 2015 at 5:29 PM, Brian Norris
> <computersforpeace@gmail.com> wrote:
> 
> >> +Required properties:
> >> +- partition-type : the type of partition. Only one type can be specified.
> >
> > You're supporting this as a list property (for future expansion,
> > presumably), so I can only assume the "only one type" is referring to
> > the number of different parsers available currently, not the behavior of
> > the property itself?
> 
> I was thinking that it would not be a list actually.
> 
> The reason being that if you're anyways going to the trouble of
> specifying exactly what partition type is going to be used, you're
> not really interested in specifying a few different ones, you know
> exactly what type it is going to be.

OK, that makes sense. I think it's still *possible* that a board might
have the option of more than one partition parser, and so they might
just include both in the DTS, but that seems unlikely and so it makes
sense not to (over)engineer for it before it's needed. Anyway, your
binding can easily be expanded in the future if needed.

> But if you think it needs to be a list, I'll specify that, no big
> deal. I'll also try to get the Linux code to handle a list then.

No, I think your proposal is OK then. It's possible there is some room
for clarification in the binding, since I was confused, but that could
mostly be attributed to my pre-existing assumptions, not a fault of the
text.

> > Also, this patch will conflict with [1]. I'll probably take [1] soon, so
> > one of us will have to rebase this.
> 
> Sure I'll rebase on whatever you say.

OK, I'll let you know.

Brian

  reply	other threads:[~2015-10-30 17:51 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-29 12:52 [PATCH 1/3] mtd: create a partition type device tree binding Linus Walleij
2015-10-29 12:52 ` [PATCH 2/3] mtd: physmap_of: break out array clone code Linus Walleij
2015-10-29 12:52 ` [PATCH 3/3] mtd: physmap_of: handle the new "partition-type" Linus Walleij
2015-10-29 16:29 ` [PATCH 1/3] mtd: create a partition type device tree binding Brian Norris
2015-10-30 14:00   ` Linus Walleij
2015-10-30 17:51     ` Brian Norris [this message]
2015-11-06 14:13       ` Rob Herring
2015-11-10  3:26         ` Brian Norris
2015-11-10  8:43           ` Linus Walleij
2015-11-13 22:00         ` Brian Norris
2015-11-14 10:46           ` Linus Walleij
2015-11-16  4:12             ` Brian Norris
2015-11-15  9:06         ` Geert Uytterhoeven

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=20151030175145.GF13239@google.com \
    --to=computersforpeace@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).