[PATCH 1/2] mtdpart: memory accessor interface for MTD layer

Sudhakar Rajashekhara sudhakar.raj at ti.com
Fri Aug 6 02:48:22 EDT 2010


On Wed, Aug 04, 2010 at 16:38:47, David Woodhouse wrote:
> On Wed, 2010-08-04 at 03:31 -0700, David Brownell wrote:
> > Point is to ensure that enough of the right context
> > information is available to initialize correctly.
> > So the right data is extracted and passed on.
> 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?

Thanks for the feedback. I'll be re-working on this patch and will re-post
the updated patch soon.


More information about the linux-mtd mailing list