From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=Plg1=CJ=lists.01.org=linux-nvdimm-bounces@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
X-Spam-Level: 
X-Spam-Status: No, score=-9.8 required=3.0 tests=BAYES_00,DKIM_INVALID,
	DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,
	SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham
	autolearn_force=no version=3.4.0
Received: from mail.kernel.org (mail.kernel.org [198.145.29.99])
	by smtp.lore.kernel.org (Postfix) with ESMTP id DC924C433E2
	for <linux-nvdimm@archiver.kernel.org>; Mon, 31 Aug 2020 10:19:19 +0000 (UTC)
Received: from ml01.01.org (ml01.01.org [198.145.21.10])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by mail.kernel.org (Postfix) with ESMTPS id A6E8B20936
	for <linux-nvdimm@archiver.kernel.org>; Mon, 31 Aug 2020 10:19:19 +0000 (UTC)
Authentication-Results: mail.kernel.org;
	dkim=fail reason="signature verification failed" (1024-bit key) header.d=citrix.com header.i=@citrix.com header.b="BHsS6ifi"
DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A6E8B20936
Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=citrix.com
Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-nvdimm-bounces@lists.01.org
Received: from ml01.vlan13.01.org (localhost [IPv6:::1])
	by ml01.01.org (Postfix) with ESMTP id 719CB139915FC;
	Mon, 31 Aug 2020 03:19:19 -0700 (PDT)
Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=216.71.155.144; helo=esa4.hc3370-68.iphmx.com; envelope-from=roger.pau@citrix.com; receiver=<UNKNOWN> 
Received: from esa4.hc3370-68.iphmx.com (esa4.hc3370-68.iphmx.com [216.71.155.144])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by ml01.01.org (Postfix) with ESMTPS id 6090C13991501
	for <linux-nvdimm@lists.01.org>; Mon, 31 Aug 2020 03:19:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
  d=citrix.com; s=securemail; t=1598869157;
  h=date:from:to:cc:subject:message-id:references:
   mime-version:content-transfer-encoding:in-reply-to;
  bh=LeOijzUwMXdvkDZh8ZExAKrzefOMcwxRYnkT30H6cak=;
  b=BHsS6ifiXDGDPhmSRFYFCRskfreHKWZZNXzDDPQ7zUgxReAs8f6lTbJk
   Xl6Fukg8Srp53QCEO8RtqW5uX2diVMVas02UgvKFJYX2m/5kUw1VFch65
   hn7a5QUnsFrg0nIhuwaPxa3aJaXtcMQqJ16Sy1qxxGnDJ9Dxw/jpicQqc
   Y=;
Authentication-Results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none
IronPort-SDR: eWPQ8PRo6r0pd8QAR03BDDXV1YAGXcgVKaAT1jr7yslt/m/BRiG+ygAM5Hg5dng98CZbXgJIRL
 TrqSjrZy6HmI3tiTkKmcBWku337jv3S0EsUktgRx6C7cUgLduAaZtZg15fyRawmnG3RAqkgmb+
 ba0pRICuEAkuQK8+Anjdo7aw0WfwKjVCCyEcDz1JvJdrf3/sLX7mleER+GXLtaVO6OxW0oqVDb
 8HGx2ZOrPZoNphcY+W0vv75NhXZGU+B3oZz0hISUUplPeCmIdQ/npzPJPsL3Tv8Q3Rl0SESIyG
 yDg=
X-SBRS: 2.7
X-MesageID: 26582307
X-Ironport-Server: esa4.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.76,375,1592884800";
   d="scan'208";a="26582307"
Date: Mon, 31 Aug 2020 12:19:07 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Dan Williams <dan.j.williams@intel.com>, David Hildenbrand
	<david@redhat.com>
Subject: Re: [PATCH v4 1/2] memremap: rename MEMORY_DEVICE_DEVDAX to
 MEMORY_DEVICE_GENERIC
Message-ID: <20200831101907.GA753@Air-de-Roger>
References: <20200811094447.31208-1-roger.pau@citrix.com>
 <20200811094447.31208-2-roger.pau@citrix.com>
 <96e34f77-8f55-d8a2-4d1f-4f4b667b0472@redhat.com>
 <20200820113741.GV828@Air-de-Roger>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <20200820113741.GV828@Air-de-Roger>
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 FTLPEX02CL06.citrite.net (10.13.108.179)
Message-ID-Hash: ERFIHR4LPZZYLC4UVXP2TNZVJGMYZJGN
X-Message-ID-Hash: ERFIHR4LPZZYLC4UVXP2TNZVJGMYZJGN
X-MailFrom: roger.pau@citrix.com
X-Mailman-Rule-Hits: nonmember-moderation
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation
CC: linux-kernel@vger.kernel.org, Andrew Morton <akpm@linux-foundation.org>, Jason Gunthorpe <jgg@ziepe.ca>, Logan Gunthorpe <logang@deltatee.com>, linux-nvdimm@lists.01.org, xen-devel@lists.xenproject.org, linux-mm@kvack.org
X-Mailman-Version: 3.1.1
Precedence: list
List-Id: "Linux-nvdimm developer list." <linux-nvdimm.lists.01.org>
Archived-At: <https://lists.01.org/hyperkitty/list/linux-nvdimm@lists.01.org/message/ERFIHR4LPZZYLC4UVXP2TNZVJGMYZJGN/>
List-Archive: <https://lists.01.org/hyperkitty/list/linux-nvdimm@lists.01.org/>
List-Help: <mailto:linux-nvdimm-request@lists.01.org?subject=help>
List-Post: <mailto:linux-nvdimm@lists.01.org>
List-Subscribe: <mailto:linux-nvdimm-join@lists.01.org>
List-Unsubscribe: <mailto:linux-nvdimm-leave@lists.01.org>
Content-Transfer-Encoding: base64

T24gVGh1LCBBdWcgMjAsIDIwMjAgYXQgMDE6Mzc6NDFQTSArMDIwMCwgUm9nZXIgUGF1IE1vbm7D
qSB3cm90ZToNCj4gT24gVHVlLCBBdWcgMTEsIDIwMjAgYXQgMTE6MDc6MzZQTSArMDIwMCwgRGF2
aWQgSGlsZGVuYnJhbmQgd3JvdGU6DQo+ID4gT24gMTEuMDguMjAgMTE6NDQsIFJvZ2VyIFBhdSBN
b25uZSB3cm90ZToNCj4gPiA+IFRoaXMgaXMgaW4gcHJlcGFyYXRpb24gZm9yIHRoZSBsb2dpYyBi
ZWhpbmQgTUVNT1JZX0RFVklDRV9ERVZEQVggYWxzbw0KPiA+ID4gYmVpbmcgdXNlZCBieSBub24g
REFYIGRldmljZXMuDQo+ID4gPiANCj4gPiA+IE5vIGZ1bmN0aW9uYWwgY2hhbmdlIGludGVuZGVk
Lg0KPiA+ID4gDQo+ID4gPiBTaWduZWQtb2ZmLWJ5OiBSb2dlciBQYXUgTW9ubsOpIDxyb2dlci5w
YXVAY2l0cml4LmNvbT4NCj4gPiA+IC0tLQ0KPiA+ID4gQ2M6IERhbiBXaWxsaWFtcyA8ZGFuLmou
d2lsbGlhbXNAaW50ZWwuY29tPg0KPiA+ID4gQ2M6IFZpc2hhbCBWZXJtYSA8dmlzaGFsLmwudmVy
bWFAaW50ZWwuY29tPg0KPiA+ID4gQ2M6IERhdmUgSmlhbmcgPGRhdmUuamlhbmdAaW50ZWwuY29t
Pg0KPiA+ID4gQ2M6IEFuZHJldyBNb3J0b24gPGFrcG1AbGludXgtZm91bmRhdGlvbi5vcmc+DQo+
ID4gPiBDYzogSmFzb24gR3VudGhvcnBlIDxqZ2dAemllcGUuY2E+DQo+ID4gPiBDYzogSXJhIFdl
aW55IDxpcmEud2VpbnlAaW50ZWwuY29tPg0KPiA+ID4gQ2M6ICJBbmVlc2ggS3VtYXIgSy5WIiA8
YW5lZXNoLmt1bWFyQGxpbnV4LmlibS5jb20+DQo+ID4gPiBDYzogSm9oYW5uZXMgVGh1bXNoaXJu
IDxqdGh1bXNoaXJuQHN1c2UuZGU+DQo+ID4gPiBDYzogTG9nYW4gR3VudGhvcnBlIDxsb2dhbmdA
ZGVsdGF0ZWUuY29tPg0KPiA+ID4gQ2M6IGxpbnV4LW52ZGltbUBsaXN0cy4wMS5vcmcNCj4gPiA+
IENjOiB4ZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcNCj4gPiA+IENjOiBsaW51eC1tbUBr
dmFjay5vcmcNCj4gPiA+IC0tLQ0KPiA+ID4gIGRyaXZlcnMvZGF4L2RldmljZS5jICAgICB8IDIg
Ky0NCj4gPiA+ICBpbmNsdWRlL2xpbnV4L21lbXJlbWFwLmggfCA5ICsrKystLS0tLQ0KPiA+ID4g
IG1tL21lbXJlbWFwLmMgICAgICAgICAgICB8IDIgKy0NCj4gPiA+ICAzIGZpbGVzIGNoYW5nZWQs
IDYgaW5zZXJ0aW9ucygrKSwgNyBkZWxldGlvbnMoLSkNCj4gPiA+IA0KPiA+ID4gZGlmZiAtLWdp
dCBhL2RyaXZlcnMvZGF4L2RldmljZS5jIGIvZHJpdmVycy9kYXgvZGV2aWNlLmMNCj4gPiA+IGlu
ZGV4IDRjMGFmMmViN2UxOS4uMWU4OTUxM2YzYzU5IDEwMDY0NA0KPiA+ID4gLS0tIGEvZHJpdmVy
cy9kYXgvZGV2aWNlLmMNCj4gPiA+ICsrKyBiL2RyaXZlcnMvZGF4L2RldmljZS5jDQo+ID4gPiBA
QCAtNDI5LDcgKzQyOSw3IEBAIGludCBkZXZfZGF4X3Byb2JlKHN0cnVjdCBkZXZpY2UgKmRldikN
Cj4gPiA+ICAJCXJldHVybiAtRUJVU1k7DQo+ID4gPiAgCX0NCj4gPiA+ICANCj4gPiA+IC0JZGV2
X2RheC0+cGdtYXAudHlwZSA9IE1FTU9SWV9ERVZJQ0VfREVWREFYOw0KPiA+ID4gKwlkZXZfZGF4
LT5wZ21hcC50eXBlID0gTUVNT1JZX0RFVklDRV9HRU5FUklDOw0KPiA+ID4gIAlhZGRyID0gZGV2
bV9tZW1yZW1hcF9wYWdlcyhkZXYsICZkZXZfZGF4LT5wZ21hcCk7DQo+ID4gPiAgCWlmIChJU19F
UlIoYWRkcikpDQo+ID4gPiAgCQlyZXR1cm4gUFRSX0VSUihhZGRyKTsNCj4gPiA+IGRpZmYgLS1n
aXQgYS9pbmNsdWRlL2xpbnV4L21lbXJlbWFwLmggYi9pbmNsdWRlL2xpbnV4L21lbXJlbWFwLmgN
Cj4gPiA+IGluZGV4IDVmNWIyZGYwNmU2MS4uZTU4NjI3NDY3NTFiIDEwMDY0NA0KPiA+ID4gLS0t
IGEvaW5jbHVkZS9saW51eC9tZW1yZW1hcC5oDQo+ID4gPiArKysgYi9pbmNsdWRlL2xpbnV4L21l
bXJlbWFwLmgNCj4gPiA+IEBAIC00NiwxMSArNDYsMTAgQEAgc3RydWN0IHZtZW1fYWx0bWFwIHsN
Cj4gPiA+ICAgKiB3YWtldXAgaXMgdXNlZCB0byBjb29yZGluYXRlIHBoeXNpY2FsIGFkZHJlc3Mg
c3BhY2UgbWFuYWdlbWVudCAoZXg6DQo+ID4gPiAgICogZnMgdHJ1bmNhdGUvaG9sZSBwdW5jaCkg
dnMgcGlubmVkIHBhZ2VzIChleDogZGV2aWNlIGRtYSkuDQo+ID4gPiAgICoNCj4gPiA+IC0gKiBN
RU1PUllfREVWSUNFX0RFVkRBWDoNCj4gPiA+ICsgKiBNRU1PUllfREVWSUNFX0dFTkVSSUM6DQo+
ID4gPiAgICogSG9zdCBtZW1vcnkgdGhhdCBoYXMgc2ltaWxhciBhY2Nlc3Mgc2VtYW50aWNzIGFz
IFN5c3RlbSBSQU0gaS5lLiBETUENCj4gPiA+IC0gKiBjb2hlcmVudCBhbmQgc3VwcG9ydHMgcGFn
ZSBwaW5uaW5nLiBJbiBjb250cmFzdCB0bw0KPiA+ID4gLSAqIE1FTU9SWV9ERVZJQ0VfRlNfREFY
LCB0aGlzIG1lbW9yeSBpcyBhY2Nlc3MgdmlhIGEgZGV2aWNlLWRheA0KPiA+ID4gLSAqIGNoYXJh
Y3RlciBkZXZpY2UuDQo+ID4gPiArICogY29oZXJlbnQgYW5kIHN1cHBvcnRzIHBhZ2UgcGlubmlu
Zy4gVGhpcyBpcyBmb3IgZXhhbXBsZSB1c2VkIGJ5IERBWCBkZXZpY2VzDQo+ID4gPiArICogdGhh
dCBleHBvc2UgbWVtb3J5IHVzaW5nIGEgY2hhcmFjdGVyIGRldmljZS4NCj4gPiA+ICAgKg0KPiA+
ID4gICAqIE1FTU9SWV9ERVZJQ0VfUENJX1AyUERNQToNCj4gPiA+ICAgKiBEZXZpY2UgbWVtb3J5
IHJlc2lkaW5nIGluIGEgUENJIEJBUiBpbnRlbmRlZCBmb3IgdXNlIHdpdGggUGVlci10by1QZWVy
DQo+ID4gPiBAQCAtNjAsNyArNTksNyBAQCBlbnVtIG1lbW9yeV90eXBlIHsNCj4gPiA+ICAJLyog
MCBpcyByZXNlcnZlZCB0byBjYXRjaCB1bmluaXRpYWxpemVkIHR5cGUgZmllbGRzICovDQo+ID4g
PiAgCU1FTU9SWV9ERVZJQ0VfUFJJVkFURSA9IDEsDQo+ID4gPiAgCU1FTU9SWV9ERVZJQ0VfRlNf
REFYLA0KPiA+ID4gLQlNRU1PUllfREVWSUNFX0RFVkRBWCwNCj4gPiA+ICsJTUVNT1JZX0RFVklD
RV9HRU5FUklDLA0KPiA+ID4gIAlNRU1PUllfREVWSUNFX1BDSV9QMlBETUEsDQo+ID4gPiAgfTsN
Cj4gPiA+ICANCj4gPiA+IGRpZmYgLS1naXQgYS9tbS9tZW1yZW1hcC5jIGIvbW0vbWVtcmVtYXAu
Yw0KPiA+ID4gaW5kZXggMDNlMzhiN2EzOGYxLi4wMDZkYWNlNjBiMWEgMTAwNjQ0DQo+ID4gPiAt
LS0gYS9tbS9tZW1yZW1hcC5jDQo+ID4gPiArKysgYi9tbS9tZW1yZW1hcC5jDQo+ID4gPiBAQCAt
MjE2LDcgKzIxNiw3IEBAIHZvaWQgKm1lbXJlbWFwX3BhZ2VzKHN0cnVjdCBkZXZfcGFnZW1hcCAq
cGdtYXAsIGludCBuaWQpDQo+ID4gPiAgCQkJcmV0dXJuIEVSUl9QVFIoLUVJTlZBTCk7DQo+ID4g
PiAgCQl9DQo+ID4gPiAgCQlicmVhazsNCj4gPiA+IC0JY2FzZSBNRU1PUllfREVWSUNFX0RFVkRB
WDoNCj4gPiA+ICsJY2FzZSBNRU1PUllfREVWSUNFX0dFTkVSSUM6DQo+ID4gPiAgCQluZWVkX2Rl
dm1hcF9tYW5hZ2VkID0gZmFsc2U7DQo+ID4gPiAgCQlicmVhazsNCj4gPiA+ICAJY2FzZSBNRU1P
UllfREVWSUNFX1BDSV9QMlBETUE6DQo+ID4gPiANCj4gPiANCj4gPiBObyBzdHJvbmcgb3Bpbmlv
biAoQERhbj8pLCBJIGRvIHdvbmRlciBpZiBhIHNlcGFyYXRlIHR5cGUgd291bGQgbWFrZSBzZW5z
ZS4NCj4gDQo+IEdlbnRsZSBwaW5nLg0KDQpTb3JyeSB0byBwaW5nIGFnYWluLCBidXQgSSB3b3Vs
ZCByYXRoZXIgZ2V0IHRoaXMgb3V0IG9mIG15IHF1ZXVlIGlmDQpwb3NzaWJsZSwgc2VlaW5nIGFz
IHRoZSBvdGhlciBwYXRjaCBpcyBPSyB0byBnbyBpbiBidXQgZGVwZW5kcyBvbiB0aGlzDQpvbmUg
Z29pbmcgaW4gZmlyc3QuDQoNClRoYW5rcywgUm9nZXIuCl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fCkxpbnV4LW52ZGltbSBtYWlsaW5nIGxpc3QgLS0gbGlu
dXgtbnZkaW1tQGxpc3RzLjAxLm9yZwpUbyB1bnN1YnNjcmliZSBzZW5kIGFuIGVtYWlsIHRvIGxp
bnV4LW52ZGltbS1sZWF2ZUBsaXN0cy4wMS5vcmcK

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=8grS=CJ=vger.kernel.org=linux-kernel-owner@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
X-Spam-Level: 
X-Spam-Status: No, score=-9.8 required=3.0 tests=BAYES_00,DKIM_INVALID,
	DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,
	SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham
	autolearn_force=no version=3.4.0
Received: from mail.kernel.org (mail.kernel.org [198.145.29.99])
	by smtp.lore.kernel.org (Postfix) with ESMTP id 1B3EBC433E2
	for <linux-kernel@archiver.kernel.org>; Mon, 31 Aug 2020 10:19:26 +0000 (UTC)
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by mail.kernel.org (Postfix) with ESMTP id EA43D2072D
	for <linux-kernel@archiver.kernel.org>; Mon, 31 Aug 2020 10:19:25 +0000 (UTC)
Authentication-Results: mail.kernel.org;
	dkim=fail reason="signature verification failed" (1024-bit key) header.d=citrix.com header.i=@citrix.com header.b="a11VaIRO"
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1726248AbgHaKTT (ORCPT
        <rfc822;linux-kernel@archiver.kernel.org>);
        Mon, 31 Aug 2020 06:19:19 -0400
Received: from esa4.hc3370-68.iphmx.com ([216.71.155.144]:26933 "EHLO
        esa4.hc3370-68.iphmx.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1726081AbgHaKTQ (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Mon, 31 Aug 2020 06:19:16 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
  d=citrix.com; s=securemail; t=1598869155;
  h=date:from:to:cc:subject:message-id:references:
   mime-version:content-transfer-encoding:in-reply-to;
  bh=LeOijzUwMXdvkDZh8ZExAKrzefOMcwxRYnkT30H6cak=;
  b=a11VaIROMwleI0rcDiUymMkflX+mbGNmlmK4b5WFu/5FTztmPb8HCJ0v
   vsayByU2oG7V3PsznIY3vhUsLnmcY+7Bmgvjk0/7hVPAd1QadEhGaUN8w
   HmTZPuXNfbDDs4UJSWTh8fKIEtJSwO6impe+V99vkX2nJ7RnskLNS6oFY
   M=;
Authentication-Results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none
IronPort-SDR: eWPQ8PRo6r0pd8QAR03BDDXV1YAGXcgVKaAT1jr7yslt/m/BRiG+ygAM5Hg5dng98CZbXgJIRL
 TrqSjrZy6HmI3tiTkKmcBWku337jv3S0EsUktgRx6C7cUgLduAaZtZg15fyRawmnG3RAqkgmb+
 ba0pRICuEAkuQK8+Anjdo7aw0WfwKjVCCyEcDz1JvJdrf3/sLX7mleER+GXLtaVO6OxW0oqVDb
 8HGx2ZOrPZoNphcY+W0vv75NhXZGU+B3oZz0hISUUplPeCmIdQ/npzPJPsL3Tv8Q3Rl0SESIyG
 yDg=
X-SBRS: 2.7
X-MesageID: 26582307
X-Ironport-Server: esa4.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.76,375,1592884800"; 
   d="scan'208";a="26582307"
Date:   Mon, 31 Aug 2020 12:19:07 +0200
From:   Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To:     Dan Williams <dan.j.williams@intel.com>,
        David Hildenbrand <david@redhat.com>
CC:     <linux-kernel@vger.kernel.org>,
        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
Message-ID: <20200831101907.GA753@Air-de-Roger>
References: <20200811094447.31208-1-roger.pau@citrix.com>
 <20200811094447.31208-2-roger.pau@citrix.com>
 <96e34f77-8f55-d8a2-4d1f-4f4b667b0472@redhat.com>
 <20200820113741.GV828@Air-de-Roger>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20200820113741.GV828@Air-de-Roger>
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 FTLPEX02CL06.citrite.net (10.13.108.179)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, Aug 20, 2020 at 01:37:41PM +0200, Roger Pau Monné wrote:
> On Tue, Aug 11, 2020 at 11:07:36PM +0200, David Hildenbrand wrote:
> > 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.
> 
> Gentle ping.

Sorry to ping again, but I would rather get this out of my queue if
possible, seeing as the other patch is OK to go in but depends on this
one going in first.

Thanks, Roger.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=BfPI=CJ=lists.xenproject.org=xen-devel-bounces@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
X-Spam-Level: 
X-Spam-Status: No, score=-9.8 required=3.0 tests=BAYES_00,DKIM_INVALID,
	DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,
	SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable
	autolearn_force=no version=3.4.0
Received: from mail.kernel.org (mail.kernel.org [198.145.29.99])
	by smtp.lore.kernel.org (Postfix) with ESMTP id 07DD6C433E2
	for <xen-devel@archiver.kernel.org>; Mon, 31 Aug 2020 10:19:42 +0000 (UTC)
Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by mail.kernel.org (Postfix) with ESMTPS id C604B2072D
	for <xen-devel@archiver.kernel.org>; Mon, 31 Aug 2020 10:19:41 +0000 (UTC)
Authentication-Results: mail.kernel.org;
	dkim=fail reason="signature verification failed" (1024-bit key) header.d=citrix.com header.i=@citrix.com header.b="RAhdZgZF"
DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C604B2072D
Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=citrix.com
Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1kCguF-0002p4-Iq; Mon, 31 Aug 2020 10:19:19 +0000
Received: from us1-rack-iad1.inumbo.com ([172.99.69.81])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=MWhU=CJ=citrix.com=roger.pau@srs-us1.protection.inumbo.net>)
 id 1kCguD-0002oK-Ti
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2020 10:19:17 +0000
X-Inumbo-ID: 9c2e8bb8-32b0-46b8-b62d-81220f531306
Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144])
 by us1-rack-iad1.inumbo.com (Halon) with ESMTPS
 id 9c2e8bb8-32b0-46b8-b62d-81220f531306;
 Mon, 31 Aug 2020 10:19:16 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=citrix.com; s=securemail; t=1598869156;
 h=date:from:to:cc:subject:message-id:references:
 mime-version:content-transfer-encoding:in-reply-to;
 bh=LeOijzUwMXdvkDZh8ZExAKrzefOMcwxRYnkT30H6cak=;
 b=RAhdZgZFsfc2Y4kygbuR45Hocoqbig8x3d5/ZfN5bSjdmaxMbYBRgpBy
 bpK1lk9blVVfD6DqExwbZPPx1YOAuu1F7Om4zJkNrtgXGuWne0dSIO3Ce
 Ln2d4KVVUC07afBDRBgc1/b5M4kHg8c4p+HW1DdoKbbsLwdUBqWVCCobx M=;
Authentication-Results: esa4.hc3370-68.iphmx.com;
 dkim=none (message not signed) header.i=none
IronPort-SDR: eWPQ8PRo6r0pd8QAR03BDDXV1YAGXcgVKaAT1jr7yslt/m/BRiG+ygAM5Hg5dng98CZbXgJIRL
 TrqSjrZy6HmI3tiTkKmcBWku337jv3S0EsUktgRx6C7cUgLduAaZtZg15fyRawmnG3RAqkgmb+
 ba0pRICuEAkuQK8+Anjdo7aw0WfwKjVCCyEcDz1JvJdrf3/sLX7mleER+GXLtaVO6OxW0oqVDb
 8HGx2ZOrPZoNphcY+W0vv75NhXZGU+B3oZz0hISUUplPeCmIdQ/npzPJPsL3Tv8Q3Rl0SESIyG
 yDg=
X-SBRS: 2.7
X-MesageID: 26582307
X-Ironport-Server: esa4.hc3370-68.iphmx.com
X-Remote-IP: 162.221.158.21
X-Policy: $RELAYED
X-IronPort-AV: E=Sophos;i="5.76,375,1592884800"; d="scan'208";a="26582307"
Date: Mon, 31 Aug 2020 12:19:07 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
To: Dan Williams <dan.j.williams@intel.com>, David Hildenbrand
 <david@redhat.com>
CC: <linux-kernel@vger.kernel.org>, 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
Message-ID: <20200831101907.GA753@Air-de-Roger>
References: <20200811094447.31208-1-roger.pau@citrix.com>
 <20200811094447.31208-2-roger.pau@citrix.com>
 <96e34f77-8f55-d8a2-4d1f-4f4b667b0472@redhat.com>
 <20200820113741.GV828@Air-de-Roger>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20200820113741.GV828@Air-de-Roger>
X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To
 FTLPEX02CL06.citrite.net (10.13.108.179)
X-BeenThere: xen-devel@lists.xenproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>

On Thu, Aug 20, 2020 at 01:37:41PM +0200, Roger Pau Monné wrote:
> On Tue, Aug 11, 2020 at 11:07:36PM +0200, David Hildenbrand wrote:
> > 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.
> 
> Gentle ping.

Sorry to ping again, but I would rather get this out of my queue if
possible, seeing as the other patch is OK to go in but depends on this
one going in first.

Thanks, Roger.