[PATCH][MTD] mtdpart.c: allow other drivers to get physical address of partition

[Jared Hulbert]

> I don't think that one is particular hard to do. All you need is:
> - count refernces in the driver

References to what? pages? pfn's?

> - make the xip code return its references after use
> - a callback that the driver can call to get its references that are
>    mapped to userland back which would simply boil down to
>    filemap_xip_unmap()

Hmm.  See problem is we don't always want to just 'zap' pages, as
such.  Though that would be the brute force straight forward approach.
 I think there is an optimization to target.

Assume we need to erase a block, this definately requires that all
pages in that block be 'zapped'.

With most flashes the erase operation takes chunks of the array larger
than the effected block offline temporarily.  Right now XIP support in
MTD just spins waiting for an interrupt.  When one is recieved the
erase is suspended and normal execution continues with just the block
being erased in an unknown state.  Then when the coast is clear the
erase is resumed.

So we have a large number of pages that are not being changed but that
are not availiable for some time.  I think it would be much better to
identify those pages that will be taken offline and change the page
tables such that a fault can be directed to the FS and then to the MTD
to do the suspend.

The reason would be fault avoidance.  See once the erase completes all
the old valid pages should be mapped back as they were.  Why not allow
the kernel to continue (assuming it isn't taken offline!) executing as
normal and why interrupt the erase until you know for sure you need to
access effected pages?

> - the driver should stop handing out new references for file
> operations when calling the callback, and the reference count should
> become zero pretty soon.
> I'd be happy to do the xip infrastructure parts of this.

Great!