On Thu, Aug 13, 2015 at 9:51 AM, Ross Zwisler
> Update the annotation for the kaddr pointer returned by direct_access()
> so that it is a __pmem pointer. This is consistent with the PMEM driver
> and with how this direct_access() pointer is used in the DAX code.
> Signed-off-by: Ross Zwisler <ross.zwisler(a)linux.intel.com>
> Documentation/filesystems/Locking | 3 ++-
> arch/powerpc/sysdev/axonram.c | 7 ++++---
> drivers/block/brd.c | 4 ++--
> drivers/nvdimm/pmem.c | 4 ++--
> drivers/s390/block/dcssblk.c | 10 +++++----
> fs/block_dev.c | 2 +-
> fs/dax.c | 44 +++++++++++++++++++++------------------
> include/linux/blkdev.h | 8 +++----
> 8 files changed, 45 insertions(+), 37 deletions(-)
> diff --git a/Documentation/filesystems/Locking b/Documentation/filesystems/Locking
> index 6a34a0f..06d4434 100644
> --- a/Documentation/filesystems/Locking
> +++ b/Documentation/filesystems/Locking
> @@ -397,7 +397,8 @@ prototypes:
> int (*release) (struct gendisk *, fmode_t);
> int (*ioctl) (struct block_device *, fmode_t, unsigned, unsigned long);
> int (*compat_ioctl) (struct block_device *, fmode_t, unsigned, unsigned
> - int (*direct_access) (struct block_device *, sector_t, void **, unsigned
> + int (*direct_access) (struct block_device *, sector_t, void __pmem **,
> + unsigned long *);
So this collides with the __pfn_t work. I think the we have a
reasonable chance of getting that in to 4.3, so I'd wait to see if we
hit any major roadblocks with that set  before merging these.
Fair enough. Yea, I hadn't merged with that series yet a) because I didn't
know when its review cycle would settle down and b) because that series hadn't
pulled in changes from Matthew for PMD support, which I was originally using
as a baseline.
I'll merge with your code for v3.