From: David Hildenbrand <david@redhat.com>
To: Roger Pau Monne <roger.pau@citrix.com>, linux-kernel@vger.kernel.org
Cc: Dan Williams <dan.j.williams@intel.com>,
Vishal Verma <vishal.l.verma@intel.com>,
Dave Jiang <dave.jiang@intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
Jason Gunthorpe <jgg@ziepe.ca>, Ira Weiny <ira.weiny@intel.com>,
"Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>,
Johannes Thumshirn <jthumshirn@suse.de>,
Logan Gunthorpe <logang@deltatee.com>,
linux-nvdimm@lists.01.org, xen-devel@lists.xenproject.org,
linux-mm@kvack.org
Subject: Re: [PATCH v4 1/2] memremap: rename MEMORY_DEVICE_DEVDAX to MEMORY_DEVICE_GENERIC
Date: Tue, 11 Aug 2020 23:07:36 +0200 [thread overview]
Message-ID: <96e34f77-8f55-d8a2-4d1f-4f4b667b0472@redhat.com> (raw)
In-Reply-To: <20200811094447.31208-2-roger.pau@citrix.com>
On 11.08.20 11:44, Roger Pau Monne wrote:
> This is in preparation for the logic behind MEMORY_DEVICE_DEVDAX also
> being used by non DAX devices.
>
> No functional change intended.
>
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> ---
> Cc: Dan Williams <dan.j.williams@intel.com>
> Cc: Vishal Verma <vishal.l.verma@intel.com>
> Cc: Dave Jiang <dave.jiang@intel.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Jason Gunthorpe <jgg@ziepe.ca>
> Cc: Ira Weiny <ira.weiny@intel.com>
> Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
> Cc: Johannes Thumshirn <jthumshirn@suse.de>
> Cc: Logan Gunthorpe <logang@deltatee.com>
> Cc: linux-nvdimm@lists.01.org
> Cc: xen-devel@lists.xenproject.org
> Cc: linux-mm@kvack.org
> ---
> drivers/dax/device.c | 2 +-
> include/linux/memremap.h | 9 ++++-----
> mm/memremap.c | 2 +-
> 3 files changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/dax/device.c b/drivers/dax/device.c
> index 4c0af2eb7e19..1e89513f3c59 100644
> --- a/drivers/dax/device.c
> +++ b/drivers/dax/device.c
> @@ -429,7 +429,7 @@ int dev_dax_probe(struct device *dev)
> return -EBUSY;
> }
>
> - dev_dax->pgmap.type = MEMORY_DEVICE_DEVDAX;
> + dev_dax->pgmap.type = MEMORY_DEVICE_GENERIC;
> addr = devm_memremap_pages(dev, &dev_dax->pgmap);
> if (IS_ERR(addr))
> return PTR_ERR(addr);
> diff --git a/include/linux/memremap.h b/include/linux/memremap.h
> index 5f5b2df06e61..e5862746751b 100644
> --- a/include/linux/memremap.h
> +++ b/include/linux/memremap.h
> @@ -46,11 +46,10 @@ struct vmem_altmap {
> * wakeup is used to coordinate physical address space management (ex:
> * fs truncate/hole punch) vs pinned pages (ex: device dma).
> *
> - * MEMORY_DEVICE_DEVDAX:
> + * MEMORY_DEVICE_GENERIC:
> * Host memory that has similar access semantics as System RAM i.e. DMA
> - * coherent and supports page pinning. In contrast to
> - * MEMORY_DEVICE_FS_DAX, this memory is access via a device-dax
> - * character device.
> + * coherent and supports page pinning. This is for example used by DAX devices
> + * that expose memory using a character device.
> *
> * MEMORY_DEVICE_PCI_P2PDMA:
> * Device memory residing in a PCI BAR intended for use with Peer-to-Peer
> @@ -60,7 +59,7 @@ enum memory_type {
> /* 0 is reserved to catch uninitialized type fields */
> MEMORY_DEVICE_PRIVATE = 1,
> MEMORY_DEVICE_FS_DAX,
> - MEMORY_DEVICE_DEVDAX,
> + MEMORY_DEVICE_GENERIC,
> MEMORY_DEVICE_PCI_P2PDMA,
> };
>
> diff --git a/mm/memremap.c b/mm/memremap.c
> index 03e38b7a38f1..006dace60b1a 100644
> --- a/mm/memremap.c
> +++ b/mm/memremap.c
> @@ -216,7 +216,7 @@ void *memremap_pages(struct dev_pagemap *pgmap, int nid)
> return ERR_PTR(-EINVAL);
> }
> break;
> - case MEMORY_DEVICE_DEVDAX:
> + case MEMORY_DEVICE_GENERIC:
> need_devmap_managed = false;
> break;
> case MEMORY_DEVICE_PCI_P2PDMA:
>
No strong opinion (@Dan?), I do wonder if a separate type would make sense.
--
Thanks,
David / dhildenb
next prev parent reply other threads:[~2020-08-11 21:07 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20200811094447.31208-1-roger.pau@citrix.com>
2020-08-11 9:44 ` [PATCH v4 1/2] memremap: rename MEMORY_DEVICE_DEVDAX to MEMORY_DEVICE_GENERIC Roger Pau Monne
2020-08-11 21:07 ` David Hildenbrand [this message]
2020-08-20 11:37 ` Roger Pau Monné
2020-08-31 10:19 ` Roger Pau Monné
2020-08-31 20:56 ` Ira Weiny
2020-08-31 19:20 ` Andrew Morton
2020-08-11 9:44 ` [PATCH v4 2/2] xen: add helpers to allocate unpopulated memory Roger Pau Monne
2020-08-12 7:28 ` Jürgen Groß
2020-08-12 7:38 ` Roger Pau Monné
2020-08-13 7:33 ` Christoph Hellwig
2020-08-13 7:54 ` Roger Pau Monné
2020-08-13 9:49 ` Daniel Vetter
2020-08-13 10:02 ` Roger Pau Monné
2020-08-14 7:29 ` Christoph Hellwig
2020-08-14 9:56 ` Roger Pau Monné
2020-08-14 10:27 ` Jürgen Groß
2020-08-14 12:47 ` Roger Pau Monné
2020-08-14 12:54 ` Jürgen Groß
2020-08-14 13:35 ` Roger Pau Monné
2020-08-14 13:52 ` Jürgen Groß
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=96e34f77-8f55-d8a2-4d1f-4f4b667b0472@redhat.com \
--to=david@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@linux.ibm.com \
--cc=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=ira.weiny@intel.com \
--cc=jgg@ziepe.ca \
--cc=jthumshirn@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-nvdimm@lists.01.org \
--cc=logang@deltatee.com \
--cc=roger.pau@citrix.com \
--cc=vishal.l.verma@intel.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).