All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Norris <computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: "Rob Herring" <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	"devicetree-spec-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<devicetree-spec-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"David Woodhouse" <dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>,
	"linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
	<linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
	"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
	"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"Jason Gunthorpe"
	<jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>,
	"Liviu Dudau" <Liviu.Dudau-5wv7dgnIgG8@public.gmane.org>,
	"Rafał Miłecki" <zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	"Hauke Mehrtens" <hauke-5/S+JYg5SzeELgA04lAiVw@public.gmane.org>,
	"Michal Suchanek"
	<hramrach-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Subject: Re: [PATCH 1/3] mtd: create a partition type device tree binding
Date: Sun, 15 Nov 2015 20:12:44 -0800	[thread overview]
Message-ID: <20151116041244.GA4021@brian-ubuntu> (raw)
In-Reply-To: <CACRpkdakyae95f_Lc-R7Uf7wndj5hyfCqqHziwmZjwm-uNkGAg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On Sat, Nov 14, 2015 at 11:46:59AM +0100, Linus Walleij wrote:
> On Fri, Nov 13, 2015 at 11:00 PM, Brian Norris
> <computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> 
> (...)
> >  (2) we should define a comptible property for the hard-coded
> >  partitioning case (e.g., compatible = "partitions")
> (...)
> > If we went with option (2), then ofpart.c could just check only for
> > 'compatible = "partitions"' (or similar), and if not found bail out.
> 
> So this "hard-coded partitioning case" the case is where all partitions
> are defined in the device tree as described in
> Documentation/devicetree/bindings/mtd/partition.txt ?

Right.

> Or is it a way to indicate that this array
> static const char * const part_probe_types_def[] = {
>         "cmdlinepart", "RedBoot", "ofpart", "ofoldpart", NULL };
> in physmap_of.c should be used?

No. At this point, I would consider that to be a legacy method. We still
have to support this for many cases (including the non-DT case; but
hopefully we can do better than that soon), and that would be an option.

> Sorry if I don't fully follow, I'm a bit stupid when it comes to the MTD
> helicopter  view of the situation.... :(

Yeah...sorry if I wasn't too clear. And I definitely don't blame you for
not understanding the mess that MTD often is :(

> > I think option (2) makes more sense. But it would require an update to
> > the binding and code for 4.4, since [1] was only introduced during this
> > release cycle.
> 
> Does that mean all old device trees that specify no compatible
> string all of a sudden stop working? We can't break the DT ABI, so I
> guess not.

No, that's not what I was intending. The binding before commmit
fe2585e9c29a ("doc: dt: mtd: support partitions in a special
'partitions' subnode") should still stay working as-is. That is, we
don't mess with the way things worked for anything that doesn't have a
'partitions' subnode. But now that we have a 'partitions' subnode (in
4.4-rc1), I'm just suggesting that we enforce this always have a
compatible property, so we can be more clear on the difference between:

	partitions {
		// do I have a
		// compatible = "partitons";
		// here?

		partition@0 {
			label = "foo-partition";
			reg = <0 0x100000>;
		};
	};

and

	partitions {
		compatible = "arm,arm-flash-structure";

		subnode {
			// what if we need something here eventually?
		};
	};

This would require some modifications to partitions.txt and to
drivers/mtd/ofpart.c.

> A bit confused here, I can't really see what I should do with the patch...

Hopefully that cleared up a bit? The code changes for my suggestion
would just be something like this, I think. (Not tested in any way.)

diff --git a/drivers/mtd/ofpart.c b/drivers/mtd/ofpart.c
index 669c3452f278..6811bc5440a4 100644
--- a/drivers/mtd/ofpart.c
+++ b/drivers/mtd/ofpart.c
@@ -50,6 +50,10 @@ static int parse_ofpart_partitions(struct mtd_info *master,
 			master->name, mtd_node->full_name);
 		ofpart_node = mtd_node;
 		dedicated = false;
+	} else {
+		/* The "partitions" subnode may belong to some other parser */
+		if (!of_device_is_compatible(ofpart_node, "partitions"))
+			return 0;
 	}
 
 	/* First count the subnodes */

I was just bringing this up for discussion, since it's related to
your/Rob's new proposal. I'll send a proper (and tested) patch, along
with a doc update, if that looks reasonable.

Brian

WARNING: multiple messages have this Message-ID (diff)
From: Brian Norris <computersforpeace@gmail.com>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: "Rob Herring" <robh@kernel.org>,
	"devicetree-spec@vger.kernel.org"
	<devicetree-spec@vger.kernel.org>,
	"David Woodhouse" <dwmw2@infradead.org>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"Jason Gunthorpe" <jgunthorpe@obsidianresearch.com>,
	"Liviu Dudau" <Liviu.Dudau@arm.com>,
	"Rafał Miłecki" <zajec5@gmail.com>,
	"Hauke Mehrtens" <hauke@hauke-m.de>,
	"Michal Suchanek" <hramrach@gmail.com>
Subject: Re: [PATCH 1/3] mtd: create a partition type device tree binding
Date: Sun, 15 Nov 2015 20:12:44 -0800	[thread overview]
Message-ID: <20151116041244.GA4021@brian-ubuntu> (raw)
In-Reply-To: <CACRpkdakyae95f_Lc-R7Uf7wndj5hyfCqqHziwmZjwm-uNkGAg@mail.gmail.com>

On Sat, Nov 14, 2015 at 11:46:59AM +0100, Linus Walleij wrote:
> On Fri, Nov 13, 2015 at 11:00 PM, Brian Norris
> <computersforpeace@gmail.com> wrote:
> 
> (...)
> >  (2) we should define a comptible property for the hard-coded
> >  partitioning case (e.g., compatible = "partitions")
> (...)
> > If we went with option (2), then ofpart.c could just check only for
> > 'compatible = "partitions"' (or similar), and if not found bail out.
> 
> So this "hard-coded partitioning case" the case is where all partitions
> are defined in the device tree as described in
> Documentation/devicetree/bindings/mtd/partition.txt ?

Right.

> Or is it a way to indicate that this array
> static const char * const part_probe_types_def[] = {
>         "cmdlinepart", "RedBoot", "ofpart", "ofoldpart", NULL };
> in physmap_of.c should be used?

No. At this point, I would consider that to be a legacy method. We still
have to support this for many cases (including the non-DT case; but
hopefully we can do better than that soon), and that would be an option.

> Sorry if I don't fully follow, I'm a bit stupid when it comes to the MTD
> helicopter  view of the situation.... :(

Yeah...sorry if I wasn't too clear. And I definitely don't blame you for
not understanding the mess that MTD often is :(

> > I think option (2) makes more sense. But it would require an update to
> > the binding and code for 4.4, since [1] was only introduced during this
> > release cycle.
> 
> Does that mean all old device trees that specify no compatible
> string all of a sudden stop working? We can't break the DT ABI, so I
> guess not.

No, that's not what I was intending. The binding before commmit
fe2585e9c29a ("doc: dt: mtd: support partitions in a special
'partitions' subnode") should still stay working as-is. That is, we
don't mess with the way things worked for anything that doesn't have a
'partitions' subnode. But now that we have a 'partitions' subnode (in
4.4-rc1), I'm just suggesting that we enforce this always have a
compatible property, so we can be more clear on the difference between:

	partitions {
		// do I have a
		// compatible = "partitons";
		// here?

		partition@0 {
			label = "foo-partition";
			reg = <0 0x100000>;
		};
	};

and

	partitions {
		compatible = "arm,arm-flash-structure";

		subnode {
			// what if we need something here eventually?
		};
	};

This would require some modifications to partitions.txt and to
drivers/mtd/ofpart.c.

> A bit confused here, I can't really see what I should do with the patch...

Hopefully that cleared up a bit? The code changes for my suggestion
would just be something like this, I think. (Not tested in any way.)

diff --git a/drivers/mtd/ofpart.c b/drivers/mtd/ofpart.c
index 669c3452f278..6811bc5440a4 100644
--- a/drivers/mtd/ofpart.c
+++ b/drivers/mtd/ofpart.c
@@ -50,6 +50,10 @@ static int parse_ofpart_partitions(struct mtd_info *master,
 			master->name, mtd_node->full_name);
 		ofpart_node = mtd_node;
 		dedicated = false;
+	} else {
+		/* The "partitions" subnode may belong to some other parser */
+		if (!of_device_is_compatible(ofpart_node, "partitions"))
+			return 0;
 	}
 
 	/* First count the subnodes */

I was just bringing this up for discussion, since it's related to
your/Rob's new proposal. I'll send a proper (and tested) patch, along
with a doc update, if that looks reasonable.

Brian

WARNING: multiple messages have this Message-ID (diff)
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: Sun, 15 Nov 2015 20:12:44 -0800	[thread overview]
Message-ID: <20151116041244.GA4021@brian-ubuntu> (raw)
In-Reply-To: <CACRpkdakyae95f_Lc-R7Uf7wndj5hyfCqqHziwmZjwm-uNkGAg@mail.gmail.com>

On Sat, Nov 14, 2015 at 11:46:59AM +0100, Linus Walleij wrote:
> On Fri, Nov 13, 2015 at 11:00 PM, Brian Norris
> <computersforpeace@gmail.com> wrote:
> 
> (...)
> >  (2) we should define a comptible property for the hard-coded
> >  partitioning case (e.g., compatible = "partitions")
> (...)
> > If we went with option (2), then ofpart.c could just check only for
> > 'compatible = "partitions"' (or similar), and if not found bail out.
> 
> So this "hard-coded partitioning case" the case is where all partitions
> are defined in the device tree as described in
> Documentation/devicetree/bindings/mtd/partition.txt ?

Right.

> Or is it a way to indicate that this array
> static const char * const part_probe_types_def[] = {
>         "cmdlinepart", "RedBoot", "ofpart", "ofoldpart", NULL };
> in physmap_of.c should be used?

No. At this point, I would consider that to be a legacy method. We still
have to support this for many cases (including the non-DT case; but
hopefully we can do better than that soon), and that would be an option.

> Sorry if I don't fully follow, I'm a bit stupid when it comes to the MTD
> helicopter  view of the situation.... :(

Yeah...sorry if I wasn't too clear. And I definitely don't blame you for
not understanding the mess that MTD often is :(

> > I think option (2) makes more sense. But it would require an update to
> > the binding and code for 4.4, since [1] was only introduced during this
> > release cycle.
> 
> Does that mean all old device trees that specify no compatible
> string all of a sudden stop working? We can't break the DT ABI, so I
> guess not.

No, that's not what I was intending. The binding before commmit
fe2585e9c29a ("doc: dt: mtd: support partitions in a special
'partitions' subnode") should still stay working as-is. That is, we
don't mess with the way things worked for anything that doesn't have a
'partitions' subnode. But now that we have a 'partitions' subnode (in
4.4-rc1), I'm just suggesting that we enforce this always have a
compatible property, so we can be more clear on the difference between:

	partitions {
		// do I have a
		// compatible = "partitons";
		// here?

		partition at 0 {
			label = "foo-partition";
			reg = <0 0x100000>;
		};
	};

and

	partitions {
		compatible = "arm,arm-flash-structure";

		subnode {
			// what if we need something here eventually?
		};
	};

This would require some modifications to partitions.txt and to
drivers/mtd/ofpart.c.

> A bit confused here, I can't really see what I should do with the patch...

Hopefully that cleared up a bit? The code changes for my suggestion
would just be something like this, I think. (Not tested in any way.)

diff --git a/drivers/mtd/ofpart.c b/drivers/mtd/ofpart.c
index 669c3452f278..6811bc5440a4 100644
--- a/drivers/mtd/ofpart.c
+++ b/drivers/mtd/ofpart.c
@@ -50,6 +50,10 @@ static int parse_ofpart_partitions(struct mtd_info *master,
 			master->name, mtd_node->full_name);
 		ofpart_node = mtd_node;
 		dedicated = false;
+	} else {
+		/* The "partitions" subnode may belong to some other parser */
+		if (!of_device_is_compatible(ofpart_node, "partitions"))
+			return 0;
 	}
 
 	/* First count the subnodes */

I was just bringing this up for discussion, since it's related to
your/Rob's new proposal. I'll send a proper (and tested) patch, along
with a doc update, if that looks reasonable.

Brian

  parent reply	other threads:[~2015-11-16  4:12 UTC|newest]

Thread overview: 37+ 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 ` Linus Walleij
2015-10-29 12:52 ` 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   ` Linus Walleij
2015-10-29 12:52 ` [PATCH 3/3] mtd: physmap_of: handle the new "partition-type" Linus Walleij
2015-10-29 12:52   ` Linus Walleij
     [not found] ` <1446123152-22666-1-git-send-email-linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2015-10-29 16:29   ` [PATCH 1/3] mtd: create a partition type device tree binding Brian Norris
2015-10-29 16:29     ` Brian Norris
2015-10-29 16:29     ` Brian Norris
2015-10-30 14:00     ` Linus Walleij
2015-10-30 14:00       ` Linus Walleij
2015-10-30 14:00       ` Linus Walleij
     [not found]       ` <CACRpkdYS5Jf8UC2K0bNdEQZDjTeZZx44Uu-kkof+9E=4Ny0oDg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-10-30 17:51         ` Brian Norris
2015-10-30 17:51           ` Brian Norris
2015-10-30 17:51           ` Brian Norris
     [not found]           ` <20151030175145.GF13239-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2015-11-06 14:13             ` Rob Herring
2015-11-06 14:13               ` Rob Herring
2015-11-06 14:13               ` Rob Herring
     [not found]               ` <CAL_JsqL2F3p7qBPbOiGytVyzF_aNLWbrCT0mAX1WZo6SxE3JoA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-11-10  3:26                 ` Brian Norris
2015-11-10  3:26                   ` Brian Norris
2015-11-10  3:26                   ` Brian Norris
     [not found]                   ` <20151110032626.GN12143-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2015-11-10  8:43                     ` Linus Walleij
2015-11-10  8:43                       ` Linus Walleij
2015-11-10  8:43                       ` Linus Walleij
2015-11-13 22:00                 ` Brian Norris
2015-11-13 22:00                   ` Brian Norris
2015-11-13 22:00                   ` Brian Norris
     [not found]                   ` <20151113220039.GA74382-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2015-11-14 10:46                     ` Linus Walleij
2015-11-14 10:46                       ` Linus Walleij
2015-11-14 10:46                       ` Linus Walleij
     [not found]                       ` <CACRpkdakyae95f_Lc-R7Uf7wndj5hyfCqqHziwmZjwm-uNkGAg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-11-16  4:12                         ` Brian Norris [this message]
2015-11-16  4:12                           ` Brian Norris
2015-11-16  4:12                           ` Brian Norris
2015-11-15  9:06                 ` Geert Uytterhoeven
2015-11-15  9:06                   ` Geert Uytterhoeven
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=20151116041244.GA4021@brian-ubuntu \
    --to=computersforpeace-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
    --cc=Liviu.Dudau-5wv7dgnIgG8@public.gmane.org \
    --cc=devicetree-spec-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@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=linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=robh-DgEjT+Ai2ygdnm+yROfE0A@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.