There can be multiple such structures, each
of which describes different data to be extracted
from different persistent media contexts.

Examples:  one context holds one MAC address (and
another, a different one) ... another might embed
calibration data; another, serial numbers; etc.

Pass the wrong context around, you've trashed all

"Initialization sequence" is a grab-bag category
that covers most init issues.

Point is to ensure that enough of the right context
information is available to initialize correctly.

Very different issue.  Seems easily fixable
if needed.  Agreed that e.g. EEPROMS won't
often be partitioned (unlike flash).



--

[ message continues ]

Forgive me if I'm being dim (and in particular, please forgive me if I'm
going over something that was already discussed; I know it's been a
while). But I don't see why it needs to be passed through the core MTD
code.

To take the simple case of an unpartitioned MTD device -- why can't the
map driver (or whatever) just call the maccessor setup function for
itself, directly, right after calling add_mtd_device() with its
newly-probed MTD device?

And for partitions, why can't it do the same, on the appropriate
partition.

OK, the answer to the latter question is that you don't actually *have*
the pointers to each partition you register. But that's easily fixed.

If we make add_mtd_partitions() take an extra 'struct mtd_info **'
argument and put pointers to the slave mtd 'devices' into that, it means
that your board driver *can* reliably get the mtd pointer for the fourth
partition, or whatever it needs. And can then just do the memory
accessor setup for itself.

Isn't that enough?

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation


--

[ message continues ]

Start with this, perhaps...

Subject: mtd/partitions: Add add_mtd_partitions_ret() function

Some callers want access to the MTD devices which get registered for
them when they call add_mtd_partitions(). Add a variant on the function
which does that.

Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>

diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c
index 4c539de..b9ee79b 100644
--- a/drivers/mtd/mtdpart.c
+++ b/drivers/mtd/mtdpart.c
@@ -522,26 +522,36 @@ out_register:
  * for reasons of data integrity.
  */
 
-int add_mtd_partitions(struct mtd_info *master,
-		       const struct mtd_partition *parts,
-		       int nbparts)
+int add_mtd_partitions_ret(struct mtd_info *master,
+			   const struct mtd_partition *parts,
+			   int nbparts, struct mtd_info ***mtds_ret)
 {
 	struct mtd_part *slave;
 	uint64_t cur_offset = 0;
+	struct mtd_info **mtds = NULL;
 	int i;
 
 	printk(KERN_NOTICE "Creating %d MTD partitions on \"%s\":\n", nbparts, master->name);
 
+	if (mtds_ret) {
+		mtds = kmalloc(sizeof(*mtds) * nbparts, GFP_KERNEL);
+		if (!mtds)
+			return -ENOMEM;
+	}
 	for (i = 0; i < nbparts; i++) {
 		slave = add_one_partition(master, parts + i, i, cur_offset);
-		if (!slave)
+		if (!slave) {
+			kfree(mtds);
 			return -ENOMEM;
+		}
 		cur_offset = slave->offset + slave->mtd.size;
 	}
 
+	if (mtds_ret)
+		*mtds_ret = mtds;
 	return 0;
 }
-EXPORT_SYMBOL(add_mtd_partitions);
+EXPORT_SYMBOL_GPL(add_mtd_partitions_ret);
 
 static DEFINE_SPINLOCK(part_parser_lock);
 static LIST_HEAD(part_parsers);
diff --git a/include/linux/mtd/partitions.h b/include/linux/mtd/partitions.h
index 274b619..f7935fa 100644
--- a/include/linux/mtd/partitions.h
+++ b/include/linux/mtd/partitions.h
@@ -49,9 +49,12 @@ struct mtd_partition {
 
 struct mtd_info;
 
-int add_mtd_partitions(struct mtd_info *, const struct mtd_partition *, int);
+int add_mtd_partitions_ret(struct mtd_info *, const struct mtd_partition *, int,
+			   struct mtd_info ***);
 int ...
[ message continues ]