We only want to modify these arrays inside the parser "drivers", so the
drivers should construct them however they like, then return them as
immutable arrays.

This will make other refactorings easier.

Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>

It's easier to refactor these parsers if the return value gets assigned
only once, just like every other MTD partition parser.

This prepares for making the second arg to the parse_fn() const. This is
OK if we construct the partitions completely first, and assign them to
the return pointer only after we're done modifying them.

Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>

A few MAINTAINERS updates, and some DT binding/documentation fixups.

Signed-off-by: Brian Norris <computersforpeace@gmail.com>

As noted here [1], there are potentially future conflicts if we try to
use MTD's "partitions" subnode to describe anything besides just the
fixed-in-the-device-tree partitions currently described in this
document. Particularly, there was a proposal to use this node for the
AFS parser too.

It can pose a (small) problem to try to differentiate the following
nodes:

	// using binding as currently specified
	partitions {
		#address-cells = <x>;
		#size-cells = <y>;
		partition@0 {
			...;
		};
	};

and

	// proposed future binding
	partitions {
		compatible = "arm,arm-flash-structure";
	};

It's especially difficult if other uses of this node start having
subnodes.

So, since the "partitions" node is new in v4.4, let's fixup the binding
before release so that it requires a compatible property, so it's much
clearer to distinguish. e.g.:

	// proposed
	partitions {
		compatible = "fixed-partitions";
		#address-cells = <x>;
		#size-cells = <y>;
		partition@0 {
			...;
		};
	};

[1] Subject: "mtd: create a partition type device tree binding"
    http://lkml.kernel.org/g/20151113220039.GA74382@google.com
    http://lists.infradead.org/pipermail/linux-mtd/2015-November/063355.html
    http://lists.infradead.org/pipermail/linux-mtd/2015-November/063364.html

Cc: Michal Suchanek <hramrach@gmail.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>

The ofpart partition parser might be run on DT-enabled systems that
don't have any "ofpart" partition subnodes at all, since "ofpart" is in
the default parser list. So don't complain loudly on every boot.

Example: using m25p80.c with no intent to use ofpart:

&spi2 {
	status = "okay";

	flash@0 {
		compatible = "jedec,spi-nor";
		reg = <0>;
	};
};

I see this warning:

[    0.588471] m25p80 spi2.0: gd25q32 (4096 Kbytes)
[    0.593091] spi2.0: 'partitions' subnode not found on /spi@ff130000/flash@0. Trying to parse direct subnodes as partitions.

Cc: Michal Suchanek <hramrach@gmail.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>

Most parsers can be handled with our new boilerplate-reducing macro.
There are a few that can't be (cmdlineparts and ofpart).

Also kill off the owner assignments, since register_mtd_parser() now
takes care of that.

Signed-off-by: Brian Norris <computersforpeace@gmail.com>

This field is no longer used anywhere, as it is superseded by
mtd->dev.of_node.

Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>

It seems more logical to use a device node directly associated with the
MTD master device (i.e., mtd->dev.of_node field) rather than requiring
auxiliary partition parser information to be passed in by the driver in
a separate struct.

This patch supports the mtd->dev.of_node field and deprecates the parser
data 'of_node' field

Driver conversions may now follow.

Additional side benefit to assigning mtd->dev.of_node rather than using
parser data: the driver core will automatically create a device -> node
symlink for us.

Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>

Parsing direct subnodes of a mtd device as partitions is unreliable
since the mtd device is also part of its bus subsystem and can contain
bus data in subnodes.

Move ofpart data to a subnode of its own so it is clear which data is
part of the partition layout.

Signed-off-by: Michal Suchanek <hramrach@gmail.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>

register_mtd_parser never fails; hence make it return void.

Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>