All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Norris <computersforpeace@gmail.com>
To: Josh Wu <josh.wu@atmel.com>
Cc: nicolas.ferre@atmel.com, plagnioj@jcrosoft.com,
	linux-mtd@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org, dedekind1@gmail.com
Subject: Re: [PATCH 6/6] mtd: ofpart: add compatible check for child nodes
Date: Tue, 11 Jun 2013 16:34:59 -0700	[thread overview]
Message-ID: <CAN8TOE-JuVAAKBR84cbs9Hge+bQ6hQpFyoSDywKvCMe7h+Lc4g@mail.gmail.com> (raw)
In-Reply-To: <1370860014-1770-7-git-send-email-josh.wu@atmel.com>

Hi Josh,

On Mon, Jun 10, 2013 at 3:26 AM, Josh Wu <josh.wu@atmel.com> wrote:
> If the child node has compatible property then it is a driver not partition.
>
> Signed-off-by: Josh Wu <josh.wu@atmel.com>
> ---
>  drivers/mtd/ofpart.c |   14 +++++++++++++-
>  1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/ofpart.c b/drivers/mtd/ofpart.c
> index 553d6d6..61ce1f8 100644
> --- a/drivers/mtd/ofpart.c
> +++ b/drivers/mtd/ofpart.c
> @@ -20,6 +20,10 @@
>  #include <linux/slab.h>
>  #include <linux/mtd/partitions.h>
>
> +static bool node_has_compatible(struct device_node *pp, int *len)
> +{
> +       return of_get_property(pp, "compatible", len);
> +}

The way the interface is named, it seems like a user only would ever
need the bool return value, not the implicit 'len' return value. So I
would write it like this:

static bool node_has_compatible(struct device_node *pp)
{
       return of_get_property(pp, "compatible", NULL);
}

>  static int parse_ofpart_partitions(struct mtd_info *master,
>                                    struct mtd_partition **pparts,
>                                    struct mtd_part_parser_data *data)
> @@ -40,8 +44,13 @@ static int parse_ofpart_partitions(struct mtd_info *master,
>         /* First count the subnodes */
>         pp = NULL;
>         nr_parts = 0;
> -       while ((pp = of_get_next_child(node, pp)))
> +       while ((pp = of_get_next_child(node, pp))) {
> +               int len;
> +               if (node_has_compatible(pp, &len))

Then this would just be:

if (node_has_compatible(pp))
...
etc. (rest snipped)

On a more important question, why does a NAND device node have
sub-nodes that are not partitions? And if such devices exist, wouldn't
it be more foolproof to establish a "compatible" property for ofpart
partitions? Of course, we'd still have to retain
backward-compatibility and allow partitions without a "compatible"
prop. But this question probably should be addressed in the commit log
and documented in Documentation/devicetree/bindings/mtd/partition.txt
; either specifying that all sub-nodes without a compatible property
must be partitions, or else some other explanation.

Brian

WARNING: multiple messages have this Message-ID (diff)
From: computersforpeace@gmail.com (Brian Norris)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 6/6] mtd: ofpart: add compatible check for child nodes
Date: Tue, 11 Jun 2013 16:34:59 -0700	[thread overview]
Message-ID: <CAN8TOE-JuVAAKBR84cbs9Hge+bQ6hQpFyoSDywKvCMe7h+Lc4g@mail.gmail.com> (raw)
In-Reply-To: <1370860014-1770-7-git-send-email-josh.wu@atmel.com>

Hi Josh,

On Mon, Jun 10, 2013 at 3:26 AM, Josh Wu <josh.wu@atmel.com> wrote:
> If the child node has compatible property then it is a driver not partition.
>
> Signed-off-by: Josh Wu <josh.wu@atmel.com>
> ---
>  drivers/mtd/ofpart.c |   14 +++++++++++++-
>  1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/ofpart.c b/drivers/mtd/ofpart.c
> index 553d6d6..61ce1f8 100644
> --- a/drivers/mtd/ofpart.c
> +++ b/drivers/mtd/ofpart.c
> @@ -20,6 +20,10 @@
>  #include <linux/slab.h>
>  #include <linux/mtd/partitions.h>
>
> +static bool node_has_compatible(struct device_node *pp, int *len)
> +{
> +       return of_get_property(pp, "compatible", len);
> +}

The way the interface is named, it seems like a user only would ever
need the bool return value, not the implicit 'len' return value. So I
would write it like this:

static bool node_has_compatible(struct device_node *pp)
{
       return of_get_property(pp, "compatible", NULL);
}

>  static int parse_ofpart_partitions(struct mtd_info *master,
>                                    struct mtd_partition **pparts,
>                                    struct mtd_part_parser_data *data)
> @@ -40,8 +44,13 @@ static int parse_ofpart_partitions(struct mtd_info *master,
>         /* First count the subnodes */
>         pp = NULL;
>         nr_parts = 0;
> -       while ((pp = of_get_next_child(node, pp)))
> +       while ((pp = of_get_next_child(node, pp))) {
> +               int len;
> +               if (node_has_compatible(pp, &len))

Then this would just be:

if (node_has_compatible(pp))
...
etc. (rest snipped)

On a more important question, why does a NAND device node have
sub-nodes that are not partitions? And if such devices exist, wouldn't
it be more foolproof to establish a "compatible" property for ofpart
partitions? Of course, we'd still have to retain
backward-compatibility and allow partitions without a "compatible"
prop. But this question probably should be addressed in the commit log
and documented in Documentation/devicetree/bindings/mtd/partition.txt
; either specifying that all sub-nodes without a compatible property
must be partitions, or else some other explanation.

Brian

  parent reply	other threads:[~2013-06-11 23:34 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-10 10:26 [PATCH v3 0/6] mtd: atmel_nand: enable Nand Flash Controller (NFC) support Josh Wu
2013-06-10 10:26 ` Josh Wu
2013-06-10 10:26 ` [PATCH 1/6] MTD: atmel_nand: use devm_xxx gpio kzalloc, gpio and ioremap Josh Wu
2013-06-10 10:26   ` Josh Wu
2013-06-10 10:26 ` [PATCH 2/6] mtd: atmel_nand: replace pmecc enable code with one function Josh Wu
2013-06-10 10:26   ` Josh Wu
2013-06-12 11:57   ` Jean-Christophe PLAGNIOL-VILLARD
2013-06-12 11:57     ` Jean-Christophe PLAGNIOL-VILLARD
2013-06-10 10:26 ` [PATCH 3/6] mtd: atmel_nand: add Nand Flash Controller (NFC) support Josh Wu
2013-06-10 10:26   ` Josh Wu
2013-06-10 13:22   ` Jean-Christophe PLAGNIOL-VILLARD
2013-06-10 13:22     ` Jean-Christophe PLAGNIOL-VILLARD
2013-06-13  1:59     ` Josh Wu
2013-06-13  1:59       ` Josh Wu
2013-06-10 10:26 ` [PATCH 4/6] mtd: atmel_nand: enable Nand Flash Controller (NFC) read data via sram Josh Wu
2013-06-10 10:26   ` Josh Wu
2013-06-12 11:58   ` Jean-Christophe PLAGNIOL-VILLARD
2013-06-12 11:58     ` Jean-Christophe PLAGNIOL-VILLARD
2013-06-10 10:26 ` [PATCH 5/6] mtd: atmel_nand: enable Nand Flash Controller (NFC) write " Josh Wu
2013-06-10 10:26   ` Josh Wu
2013-06-12 11:58   ` Jean-Christophe PLAGNIOL-VILLARD
2013-06-12 11:58     ` Jean-Christophe PLAGNIOL-VILLARD
2013-06-10 10:26 ` [PATCH 6/6] mtd: ofpart: add compatible check for child nodes Josh Wu
2013-06-10 10:26   ` Josh Wu
2013-06-10 12:35   ` Sergei Shtylyov
2013-06-10 12:35     ` Sergei Shtylyov
2013-06-13  3:42     ` Josh Wu
2013-06-13  3:42       ` Josh Wu
2013-06-13 13:13       ` Sergei Shtylyov
2013-06-13 13:13         ` Sergei Shtylyov
2013-06-11 23:34   ` Brian Norris [this message]
2013-06-11 23:34     ` Brian Norris
2013-06-13  3:38     ` Josh Wu
2013-06-13  3:38       ` Josh Wu
2013-06-19  6:23 [PATCH v4 0/6] mtd: atmel_nand: enable Nand Flash Controller (NFC) support Josh Wu
2013-06-19  6:23 ` [PATCH 6/6] mtd: ofpart: add compatible check for child nodes Josh Wu
2013-06-19  6:23   ` Josh Wu
2013-07-03  9:50 [PATCH v5 0/6] mtd: atmel_nand: enable Nand Flash Controller (NFC) support Josh Wu
2013-07-03  9:50 ` [PATCH 6/6] mtd: ofpart: add compatible check for child nodes Josh Wu
2013-07-03  9:50   ` Josh Wu
2013-07-18  7:14   ` Brian Norris
2013-07-18  7:14     ` Brian Norris
2013-07-18  7:14     ` Brian Norris
2013-07-18  8:28     ` Jean-Christophe PLAGNIOL-VILLARD
2013-07-18  8:28       ` Jean-Christophe PLAGNIOL-VILLARD
2013-07-18  8:28       ` Jean-Christophe PLAGNIOL-VILLARD
2013-08-05 11:14 [PATCH v6 0/6] mtd: atmel_nand: enable Nand Flash Controller (NFC) support Josh Wu
2013-08-05 11:14 ` [PATCH 6/6] mtd: ofpart: add compatible check for child nodes Josh Wu
2013-08-05 11:14   ` Josh Wu
2013-08-05 11:33   ` Josh Wu
2013-08-05 11:33     ` Josh Wu
2013-08-05 11:33     ` Josh Wu
2013-08-05 18:56     ` Brian Norris
2013-08-05 18:56       ` 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=CAN8TOE-JuVAAKBR84cbs9Hge+bQ6hQpFyoSDywKvCMe7h+Lc4g@mail.gmail.com \
    --to=computersforpeace@gmail.com \
    --cc=dedekind1@gmail.com \
    --cc=josh.wu@atmel.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=nicolas.ferre@atmel.com \
    --cc=plagnioj@jcrosoft.com \
    /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.