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
next prev 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: linkBe 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.