[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
Hi,
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.
Regards,
Sudhakar
More information about the linux-mtd
mailing list