Changes in Kconfig

1b5695b0 - mm: make range-to-target_node lookup facility a part of numa_memblks

Wed, 07 Aug 2024 06:41:09 +0000

mm: make range-to-target_node lookup facility a part of numa_memblksThe x86 implementation of range-to-target_node lookup (i.e. phys_to_target_node() and memory_add_physaddr_to_nid()) relies onnuma_memblks.Since numa_memblks are now part of the generic code, move these functionsfrom x86 to mm/numa_memblks.c and select CONFIG_NUMA_KEEP_MEMINFO whenCONFIG_NUMA_MEMBLKS=y for dax and cxl.[rppt@kernel.org: fix build] Link: https://lkml.kernel.org/r/ZtVfSt_zloPdDqVB@kernel.orgLink: https://lkml.kernel.org/r/20240807064110.1003856-26-rppt@kernel.orgSigned-off-by: Mike Rapoport (Microsoft) Reviewed-by: Jonathan Cameron Tested-by: Zi Yan # for x86_64 and arm64Tested-by: Jonathan Cameron [arm64 + CXL via QEMU]Reviewed-by: Dan Williams Acked-by: David Hildenbrand Cc: Alexander Gordeev Cc: Andreas Larsson Cc: Arnd Bergmann Cc: Borislav Petkov Cc: Catalin Marinas Cc: Christophe Leroy Cc: Dave Hansen Cc: Davidlohr Bueso Cc: David S. Miller Cc: Greg Kroah-Hartman Cc: Heiko Carstens Cc: Huacai Chen Cc: Ingo Molnar Cc: Jiaxun Yang Cc: John Paul Adrian Glaubitz Cc: Jonathan Corbet Cc: Michael Ellerman Cc: Palmer Dabbelt Cc: Rafael J. Wysocki Cc: Rob Herring (Arm) Cc: Samuel Holland Cc: Thomas Bogendoerfer Cc: Thomas Gleixner Cc: Vasily Gorbik Cc: Will Deacon Signed-off-by: Andrew Morton List of files: /linux-6.15/drivers/dax/Kconfig

0c16c83e - dax: cxl: add CXL_REGION dependency

Tue, 14 Feb 2023 10:30:49 +0000

dax: cxl: add CXL_REGION dependencyThere is already a dependency on CXL_REGION, which depends on CXL_BUS,but since CXL_REGION is a 'bool' symbol, it's possible to configureDAX as built-in even though CXL itself is a loadable module:x86_64-linux-ld: drivers/dax/cxl.o: in function `cxl_dax_region_probe':cxl.c:(.text+0xb): undefined reference to `to_cxl_dax_region'x86_64-linux-ld: drivers/dax/cxl.o: in function `cxl_dax_region_driver_init':cxl.c:(.init.text+0x10): undefined reference to `__cxl_driver_register'x86_64-linux-ld: drivers/dax/cxl.o: in function `cxl_dax_region_driver_exit':cxl.c:(.exit.text+0x9): undefined reference to `cxl_driver_unregister'Prevent this with another depndency on the tristate symbol.Fixes: 09d09e04d2fc ("cxl/dax: Create dax devices for CXL RAM regions")Signed-off-by: Arnd Bergmann Link: https://lore.kernel.org/r/20230214103054.1082908-1-arnd@kernel.orgSigned-off-by: Dan Williams List of files: /linux-6.15/drivers/dax/Kconfig

09d09e04 - cxl/dax: Create dax devices for CXL RAM regions

Fri, 10 Feb 2023 09:07:19 +0000

cxl/dax: Create dax devices for CXL RAM regionsWhile platform firmware takes some responsibility for mapping the RAMcapacity of CXL devices present at boot, the OS is responsible formapping the remainder and hot-added devices. Platform firmware is alsoresponsible for identifying the platform general purpose memory pool,typically DDR attached DRAM, and arranging for the remainder to be 'SoftReserved'. That reservation allows the CXL subsystem to route the memoryto core-mm via memory-hotplug (dax_kmem), or leave it for dedicatedaccess (device-dax).The new 'struct cxl_dax_region' object allows for a CXL memory resource(region) to be published, but also allow for udev and module policy toact on that event. It also prevents cxl_core.ko from having a moduleloading dependency on any drivers/dax/ modules.Tested-by: Fan Ni Reviewed-by: Dave Jiang Reviewed-by: Jonathan Cameron Link: https://lore.kernel.org/r/167602003896.1924368.10335442077318970468.stgit@dwillia2-xfh.jf.intel.comSigned-off-by: Dan Williams List of files: /linux-6.15/drivers/dax/Kconfig

e9ee9fe3 - dax: Assign RAM regions to memory-hotplug by default

Fri, 10 Feb 2023 09:07:13 +0000

dax: Assign RAM regions to memory-hotplug by defaultThe default mode for device-dax instances is backwards for RAM-regionsas evidenced by the fact that it tends to catch end users by surprise."Where is my memory?". Recall that platforms are increasingly shippingwith performance-differentiated memory pools beyond typical DRAM andNUMA effects. This includes HBM (high-bandwidth-memory) and CXL (dynamicinterleave, varied media types, and future fabric attachedpossibilities).For this reason the EFI_MEMORY_SP (EFI Special Purpose Memory => Linux'Soft Reserved') attribute is expected to be applied to all memory-poolsthat are not the general purpose pool. This designation gives anOperating System a chance to defer usage of a memory pool until later inthe boot process where its performance properties can be interrogatedand administrator policy can be applied.'Soft Reserved' memory can be anything from too limited and precious tobe part of the general purpose pool (HBM), too slow to host hot kerneldata structures (some PMEM media), or anything in between. However, inthe absence of an explicit policy, the memory should at least be madeusable by default. The current device-dax default hides allnon-general-purpose memory behind a device interface.The expectation is that the distribution of users that want the memoryonline by default vs device-dedicated-access by default follows thePareto principle. A small number of enlightened users may want to douserspace memory management through a device, but general users justwant the kernel to make the memory available with an option to get moreadvanced later.Arrange for all device-dax instances not backed by PMEM to default toattaching to the dax_kmem driver. From there the baseline memory hotplugpolicy (CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE / memhp_default_state=)gates whether the memory comes online or stays offline. Where, if itstays offline, it can be reliably converted back to device-mode where itcan be partitioned, or fronted by a userspace allocator.So, if someone wants device-dax instances for their 'Soft Reserved'memory:1/ Build a kernel with CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE=n or boot with memhp_default_state=offline, or roll the dice and hope that the kernel has not pinned a page in that memory before step 2.2/ Write a udev rule to convert the target dax device(s) from 'system-ram' mode to 'devdax' mode: daxctl reconfigure-device $dax -m devdax -fCc: Michal Hocko Cc: David Hildenbrand Cc: Dave Hansen Reviewed-by: Gregory Price Tested-by: Fan Ni Reviewed-by: Dave Jiang Link: https://lore.kernel.org/r/167602003336.1924368.6809503401422267885.stgit@dwillia2-xfh.jf.intel.comSigned-off-by: Dan Williams List of files: /linux-6.15/drivers/dax/Kconfig

7dab174e - dax/hmem: Move hmem device registration to dax_hmem.ko

Fri, 10 Feb 2023 09:07:07 +0000

dax/hmem: Move hmem device registration to dax_hmem.koIn preparation for the CXL region driver to take over the responsibilityof registering device-dax instances for CXL regions, move theregistration of "hmem" devices to dax_hmem.ko.Previously the builtin component of this enabling(drivers/dax/hmem/device.o) would register platform devices for eachaddress range and trigger the dax_hmem.ko module to load and attachdevice-dax instances to those devices. Now, the ranges are collectedfrom the HMAT and EFI memory map walking, but the device creation isdeferred. A new "hmem_platform" device is created which triggersdax_hmem.ko to load and register the platform devices.Tested-by: Fan Ni Reviewed-by: Dave Jiang Reviewed-by: Jonathan Cameron Link: https://lore.kernel.org/r/167602002771.1924368.5653558226424530127.stgit@dwillia2-xfh.jf.intel.comSigned-off-by: Dan Williams List of files: /linux-6.15/drivers/dax/Kconfig

a870acc1 - drivers/dax: Remove "select SRCU"

Wed, 23 Nov 2022 00:59:03 +0000

drivers/dax: Remove "select SRCU"Now that the SRCU Kconfig option is unconditionally selected, there isno longer any point in selecting it. Therefore, remove the "select SRCU"Kconfig statements.Signed-off-by: Paul E. McKenney Cc: Dan Williams Cc: Vishal Verma Cc: Dave Jiang Cc: Acked-by: Dan Williams Reviewed-by: John Ogness List of files: /linux-6.15/drivers/dax/Kconfig

afd586f0 - dax: remove CONFIG_DAX_DRIVER

Mon, 29 Nov 2021 10:21:37 +0000

dax: remove CONFIG_DAX_DRIVERCONFIG_DAX_DRIVER only selects CONFIG_DAX now, so remove it.Signed-off-by: Christoph Hellwig Reviewed-by: Dan Williams Link: https://lore.kernel.org/r/20211129102203.2243509-4-hch@lst.deSigned-off-by: Dan Williams List of files: /linux-6.15/drivers/dax/Kconfig

83762cb5 - dax: Kill DEV_DAX_PMEM_COMPAT

Mon, 15 Nov 2021 21:20:57 +0000

dax: Kill DEV_DAX_PMEM_COMPATThe /sys/class/dax compatibility option has shipped in the kernel for 4years now which should be sufficient time for tools to abandon the oldABI in favor of the /sys/bus/dax device-model. Delete it now and see ifanyone screams.Since this compatibility option shipped there has been more reports ofusers being surprised by the compat ABI than surprised by the "new", sothe compat infrastructure has outlived its usefulness. Recall that/sys/bus/dax device-model is required for the dax kmem driver whichallows PMEM to be used as "System RAM".The following projects were known to have a dependency on /sys/class/daxand have dropped their dependency as of the listed version:- ndctl (including libndctl, daxctl, and libdaxctl): v64+- fio: v3.13+- pmdk: v1.5.2+As further evidence this option is no longer needed some distributionshave already stopped enabling CONFIG_DEV_DAX_PMEM_COMPAT.Cc: Ira Weiny Cc: Dave Jiang Reported-by: Vishal Verma Acked-by: Dave Hansen Reviewed-by: Jane Chu Link: https://lore.kernel.org/r/163701116195.3784476.726128179293466337.stgit@dwillia2-desk3.amr.corp.intel.comSigned-off-by: Dan Williams List of files: /linux-6.15/drivers/dax/Kconfig

a927bd6b - mm: fix phys_to_target_node() and memory_add_physaddr_to_nid() exports

Sun, 22 Nov 2020 06:17:05 +0000

mm: fix phys_to_target_node() and memory_add_physaddr_to_nid() exportsThe core-mm has a default __weak implementation of phys_to_target_node()to mirror the weak definition of memory_add_physaddr_to_nid(). Thatsymbol is exported for modules. However, while the export inmm/memory_hotplug.c exported the symbol in the configuration cases of: CONFIG_NUMA_KEEP_MEMINFO=y CONFIG_MEMORY_HOTPLUG=y...and: CONFIG_NUMA_KEEP_MEMINFO=n CONFIG_MEMORY_HOTPLUG=y...it failed to export the symbol in the case of: CONFIG_NUMA_KEEP_MEMINFO=y CONFIG_MEMORY_HOTPLUG=nNot only is that broken, but Christoph points out that the kernel shouldnot be exporting any __weak symbol, which means thatmemory_add_physaddr_to_nid() example that phys_to_target_node() copiedis broken too.Rework the definition of phys_to_target_node() andmemory_add_physaddr_to_nid() to not require weak symbols. Move to thecommon arch override design-pattern of an asm header defining a symbolto replace the default implementation.The only common header that all memory_add_physaddr_to_nid() producingarchitectures implement is asm/sparsemem.h. In fact, powerpc alreadydefines its memory_add_physaddr_to_nid() helper in sparsemem.h.Double-down on that observation and define phys_to_target_node() wherenecessary in asm/sparsemem.h. An alternate consideration that wasdiscarded was to put this override in asm/numa.h, but that entangleswith the definition of MAX_NUMNODES relative to the inclusion oflinux/nodemask.h, and requires powerpc to grow a new header.The dependency on NUMA_KEEP_MEMINFO for DEV_DAX_HMEM_DEVICES is invalidnow that the symbol is properly exported / stubbed in all combinationsof CONFIG_NUMA_KEEP_MEMINFO and CONFIG_MEMORY_HOTPLUG.[dan.j.williams@intel.com: v4] Link: https://lkml.kernel.org/r/160461461867.1505359.5301571728749534585.stgit@dwillia2-desk3.amr.corp.intel.com[dan.j.williams@intel.com: powerpc: fix create_section_mapping compile warning] Link: https://lkml.kernel.org/r/160558386174.2948926.2740149041249041764.stgit@dwillia2-desk3.amr.corp.intel.comFixes: a035b6bf863e ("mm/memory_hotplug: introduce default phys_to_target_node() implementation")Reported-by: Randy Dunlap Reported-by: Thomas Gleixner Reported-by: kernel test robot Reported-by: Christoph Hellwig Signed-off-by: Dan Williams Signed-off-by: Andrew Morton Tested-by: Randy Dunlap Tested-by: Thomas Gleixner Reviewed-by: Thomas Gleixner Reviewed-by: Christoph Hellwig Cc: Joao Martins Cc: Tony Luck Cc: Fenghua Yu Cc: Michael Ellerman Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Vishal Verma Cc: Stephen Rothwell Link: https://lkml.kernel.org/r/160447639846.1133764.7044090803980177548.stgit@dwillia2-desk3.amr.corp.intel.comSigned-off-by: Linus Torvalds List of files: /linux-6.15/drivers/dax/Kconfig

5ccac54f - ACPI: HMAT: attach a device for each soft-reserved range

Tue, 13 Oct 2020 23:49:28 +0000

ACPI: HMAT: attach a device for each soft-reserved rangeThe hmem enabling in commit cf8741ac57ed ("ACPI: NUMA: HMAT: Register"soft reserved" memory as an "hmem" device") only registered ranges to thehmem driver for each soft-reservation that also appeared in the HMAT.While this is meant to encourage platform firmware to "do the right thing"and publish an HMAT, the corollary is that platforms that fail to publishan accurate HMAT will strand memory from Linux usage. Additionally, the"efi_fake_mem" kernel command line option enabling will strand memory bydefault without an HMAT.Arrange for "soft reserved" memory that goes unclaimed by HMAT entries tobe published as raw resource ranges for the hmem driver to consume.Include a module parameter to disable either this fallback behavior, orthe hmat enabling from creating hmem devices. The module parameterrequires the hmem device enabling to have unique name in the modulenamespace: "device_hmem".The driver depends on the architecture providing phys_to_target_node()which is only x86 via numa_meminfo() and arm64 via a generic memblockimplementation.[joao.m.martins@oracle.com: require NUMA_KEEP_MEMINFO for phys_to_target_node()] Link: https://lkml.kernel.org/r/aaae71a7-4846-f5cc-5acf-cf05fdb1f2dc@oracle.comSigned-off-by: Dan Williams Signed-off-by: Joao Martins Signed-off-by: Andrew Morton Reviewed-by: Joao Martins Cc: Jonathan Cameron Cc: Brice Goglin Cc: Jeff Moyer Cc: Catalin Marinas Cc: Will Deacon Cc: Andy Lutomirski Cc: Ard Biesheuvel Cc: Benjamin Herrenschmidt Cc: Ben Skeggs Cc: Borislav Petkov Cc: Daniel Vetter Cc: Dave Hansen Cc: Dave Jiang Cc: David Airlie Cc: David Hildenbrand Cc: Greg Kroah-Hartman Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Ira Weiny Cc: Jason Gunthorpe Cc: Jia He Cc: Michael Ellerman Cc: Mike Rapoport Cc: Paul Mackerras Cc: Pavel Tatashin Cc: Peter Zijlstra Cc: Rafael J. Wysocki Cc: Thomas Gleixner Cc: Tom Lendacky Cc: Vishal Verma Cc: Wei Yang Cc: Ard Biesheuvel Cc: Bjorn Helgaas Cc: Boris Ostrovsky Cc: Hulk Robot Cc: Jason Yan Cc: "Jérôme Glisse" Cc: Juergen Gross Cc: kernel test robot Cc: Randy Dunlap Cc: Stefano Stabellini Cc: Vivek Goyal Link: https://lkml.kernel.org/r/159643098298.4062302.17587338161136144730.stgit@dwillia2-desk3.amr.corp.intel.comSigned-off-by: Linus Torvalds List of files: /linux-6.15/drivers/dax/Kconfig

c01044cc - ACPI: HMAT: refactor hmat_register_target_device to hmem_register_device

Tue, 13 Oct 2020 23:49:13 +0000

ACPI: HMAT: refactor hmat_register_target_device to hmem_register_deviceIn preparation for exposing "Soft Reserved" memory ranges without an HMAT,move the hmem device registration to its own compilation unit and make theimplementation generic.The generic implementation drops usage acpi_map_pxm_to_online_node() thatwas translating ACPI proximity domain values and instead relies onnuma_map_to_online_node() to determine the numa node for the device.[joao.m.martins@oracle.com: CONFIG_DEV_DAX_HMEM_DEVICES should depend on CONFIG_DAX=y] Link: https://lkml.kernel.org/r/8f34727f-ec2d-9395-cb18-969ec8a5d0d4@oracle.comSigned-off-by: Dan Williams Signed-off-by: Joao Martins Signed-off-by: Andrew Morton Cc: Andy Lutomirski Cc: Benjamin Herrenschmidt Cc: Ben Skeggs Cc: Borislav Petkov Cc: Brice Goglin Cc: Catalin Marinas Cc: Daniel Vetter Cc: Dave Hansen Cc: Dave Jiang Cc: David Airlie Cc: David Hildenbrand Cc: Greg Kroah-Hartman Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Ira Weiny Cc: Jason Gunthorpe Cc: Jeff Moyer Cc: Jia He Cc: Joao Martins Cc: Jonathan Cameron Cc: Michael Ellerman Cc: Mike Rapoport Cc: Paul Mackerras Cc: Pavel Tatashin Cc: Peter Zijlstra Cc: Rafael J. Wysocki Cc: Thomas Gleixner Cc: Tom Lendacky Cc: Vishal Verma Cc: Wei Yang Cc: Will Deacon Cc: Ard Biesheuvel Cc: Ard Biesheuvel Cc: Bjorn Helgaas Cc: Boris Ostrovsky Cc: Hulk Robot Cc: Jason Yan Cc: "Jérôme Glisse" Cc: Juergen Gross Cc: kernel test robot Cc: Randy Dunlap Cc: Stefano Stabellini Cc: Vivek Goyal Link: https://lkml.kernel.org/r/159643096584.4062302.5035370788475153738.stgit@dwillia2-desk3.amr.corp.intel.comLink: https://lore.kernel.org/r/158318761484.2216124.2049322072599482736.stgit@dwillia2-desk3.amr.corp.intel.comSigned-off-by: Linus Torvalds List of files: /linux-6.15/drivers/dax/Kconfig

a6c7f4c6 - device-dax: Add a driver for "hmem" devices

Thu, 07 Nov 2019 01:43:43 +0000

device-dax: Add a driver for "hmem" devicesPlatform firmware like EFI/ACPI may publish "hmem" platform devices.Such a device is a performance differentiated memory range likelyreserved for an application specific use case. The driver gives accessto 100% of the capacity via a device-dax mmap instance by default.However, if over-subscription and other kernel memory management isdesired the resulting dax device can be assigned to the core-mm via thekmem driver.This consumes "hmem" devices the producer of "hmem" devices is saved fora follow-on patch so that it can reference the new CONFIG_DEV_DAX_HMEMsymbol to gate performing the enumeration work.Reported-by: kbuild test robot Reviewed-by: Dave Hansen Signed-off-by: Dan Williams Acked-by: Thomas Gleixner Signed-off-by: Rafael J. Wysocki List of files: /linux-6.15/drivers/dax/Kconfig

ec8f24b7 - treewide: Add SPDX license identifier - Makefile/Kconfig

Sun, 19 May 2019 12:07:45 +0000

treewide: Add SPDX license identifier - Makefile/KconfigAdd SPDX license identifiers to all Make/Kconfig files which: - Have no license information of any formThese files fall under the project license, GPL v2 only. The resulting SPDXlicense identifier is: GPL-2.0-onlySigned-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman List of files: /linux-6.15/drivers/dax/Kconfig

67476656 - drivers/dax: Allow to include DEV_DAX_PMEM as builtin

Mon, 01 Apr 2019 05:14:21 +0000

drivers/dax: Allow to include DEV_DAX_PMEM as builtinThis move the dependency to DEV_DAX_PMEM_COMPAT such that onlyif DEV_DAX_PMEM is built as module we can allow the compat support.This allows to test the new code easily in a emulation setup where weoften build things without module support.Cc: Fixes: 730926c3b099 ("device-dax: Add /sys/class/dax backwards compatibility")Signed-off-by: Aneesh Kumar K.V Signed-off-by: Dan Williams List of files: /linux-6.15/drivers/dax/Kconfig

c221c0b0 - device-dax: "Hotplug" persistent memory for use like normal RAM

Mon, 25 Feb 2019 18:57:40 +0000

device-dax: "Hotplug" persistent memory for use like normal RAMThis is intended for use with NVDIMMs that are physically persistent(physically like flash) so that they can be used as a cost-effectiveRAM replacement. Intel Optane DC persistent memory is oneimplementation of this kind of NVDIMM.Currently, a persistent memory region is "owned" by a device driver,either the "Direct DAX" or "Filesystem DAX" drivers. These driversallow applications to explicitly use persistent memory, generallyby being modified to use special, new libraries. (DIMM-basedpersistent memory hardware/software is described in great detailhere: Documentation/nvdimm/nvdimm.txt).However, this limits persistent memory use to applications which*have* been modified. To make it more broadly usable, this driver"hotplugs" memory into the kernel, to be managed and used just likenormal RAM would be.To make this work, management software must remove the device frombeing controlled by the "Device DAX" infrastructure: echo dax0.0 > /sys/bus/dax/drivers/device_dax/unbindand then tell the new driver that it can bind to the device: echo dax0.0 > /sys/bus/dax/drivers/kmem/new_idAfter this, there will be a number of new memory sections visiblein sysfs that can be onlined, or that may get onlined by existingudev-initiated memory hotplug rules.This rebinding procedure is currently a one-way trip. Once memoryis bound to "kmem", it's there permanently and can not beunbound and assigned back to device_dax.The kmem driver will never bind to a dax device unless the deviceis *explicitly* bound to the driver. There are two reasons forthis: One, since it is a one-way trip, it can not be undone ifbound incorrectly. Two, the kmem driver destroys data on thedevice. Think of if you had good data on a pmem device. Itwould be catastrophic if you compile-in "kmem", but leave outthe "device_dax" driver. kmem would take over the device andwrite volatile data all over your good data.This inherits any existing NUMA information for the newly-addedmemory from the persistent memory device that came from thefirmware. On Intel platforms, the firmware has guarantees thatrequire each socket's persistent memory to be in a separatememory-only NUMA node. That means that this patch is not expectedto create NUMA nodes, but will simply hotplug memory into existingnodes.Because NUMA nodes are created, the existing NUMA APIs and toolsare sufficient to create policies for applications or memory areasto have affinity for or an aversion to using this memory.There is currently some metadata at the beginning of pmem regions.The section-size memory hotplug restrictions, plus this smallreserved area can cause the "loss" of a section or two of capacity.This should be fixable in follow-on patches. But, as a first step,losing 256MB of memory (worst case) out of hundreds of gigabytesis a good tradeoff vs. the required code to fix this up precisely.This calculation is also the reason we exportmemory_block_size_bytes().Signed-off-by: Dave Hansen Reviewed-by: Dan Williams Reviewed-by: Keith Busch Cc: Dave Jiang Cc: Ross Zwisler Cc: Vishal Verma Cc: Tom Lendacky Cc: Andrew Morton Cc: Michal Hocko Cc: linux-nvdimm@lists.01.orgCc: linux-kernel@vger.kernel.orgCc: linux-mm@kvack.orgCc: Huang Ying Cc: Fengguang Wu Cc: Borislav Petkov Cc: Bjorn Helgaas Cc: Yaowei Bai Cc: Takashi Iwai Cc: Jerome Glisse Reviewed-by: Vishal Verma Signed-off-by: Dan Williams List of files: /linux-6.15/drivers/dax/Kconfig

730926c3 - device-dax: Add /sys/class/dax backwards compatibility

Sun, 16 Jul 2017 20:51:53 +0000

device-dax: Add /sys/class/dax backwards compatibilityOn the expectation that some environments may not upgrade libdaxctl(userspace component that depends on the /sys/class/dax hierarchy),provide a default / legacy dax_pmem_compat driver. The dax_pmem_compatdriver implements the original /sys/class/dax sysfs layout rather than/sys/bus/dax. When userspace is upgraded it can blacklist this moduleand switch to the dax_pmem driver going forward.CONFIG_DEV_DAX_PMEM_COMPAT and supporting code will be deleted accordingto the dax_pmem entry in Documentation/ABI/obsolete/.Signed-off-by: Dan Williams List of files: /linux-6.15/drivers/dax/Kconfig

2080e88a - dax: introduce CONFIG_DAX_DRIVER

Fri, 30 Mar 2018 00:20:39 +0000

dax: introduce CONFIG_DAX_DRIVERIn support of allowing device-mapper to compile out idle/dead code whenthere are no dax providers in the system, introduce the DAX_DRIVERsymbol. This is selected by all leaf drivers that device-mapper might belayered on top. This allows device-mapper to conditionally 'select DAX'only when a provider is present.Cc: Martin Schwidefsky Cc: Heiko Carstens Reported-by: Bart Van Assche Reviewed-by: Mike Snitzer Signed-off-by: Dan Williams List of files: /linux-6.15/drivers/dax/Kconfig

cf1e2289 - device-dax: kill NR_DEV_DAX

Mon, 08 May 2017 19:33:53 +0000

device-dax: kill NR_DEV_DAXThere is no point to ask how many device-dax instances the kernel shouldsupport. Since we are already using a dynamic major number, just allowthe max number of minors by default and be done. This also fixes thefact that the proposed max for the NR_DEV_DAX range was larger than whatcould be supported by alloc_chrdev_region().Fixes: ba09c01d2fa8 ("dax: convert to the cdev api")Reported-by: Geert Uytterhoeven Tested-by: Geert Uytterhoeven Signed-off-by: Dan Williams List of files: /linux-6.15/drivers/dax/Kconfig

74d71a01 - device-dax: Tell kbuild DEV_DAX_PMEM depends on DEV_DAX

Sat, 06 May 2017 04:14:43 +0000

device-dax: Tell kbuild DEV_DAX_PMEM depends on DEV_DAXERROR: "devm_create_dev_dax" [drivers/dax/dax_pmem.ko] undefined!ERROR: "alloc_dax_region" [drivers/dax/dax_pmem.ko] undefined!ERROR: "dax_region_put" [drivers/dax/dax_pmem.ko] undefined!Signed-off-by: Mike Galbraith Signed-off-by: Dan Williams List of files: /linux-6.15/drivers/dax/Kconfig

7b6be844 - dax: refactor dax-fs into a generic provider of 'struct dax_device' instances

Tue, 11 Apr 2017 16:49:49 +0000

dax: refactor dax-fs into a generic provider of 'struct dax_device' instancesWe want dax capable drivers to be able to publish a set of daxoperations [1]. However, we do not want to further abuse block_devicesto advertise these operations. Instead we will attach these operationsto a dax device and add a lookup mechanism to go from block device pathto a dax device. A dax capable driver like pmem or brd is responsiblefor registering a dax device, alongside a block device, and then a daxcapable filesystem is responsible for retrieving the dax device by pathname if it wants to call dax_operations.For now, we refactor the dax pseudo-fs to be a generic facility, ratherthan an implementation detail, of the device-dax use case. Where a "daxdevice" is just an inode + dax infrastructure, and "Device DAX" is amapping service layered on top of that base 'struct dax_device'."Filesystem DAX" is then a mapping service that layers a filesystem ontop of that same base device. Filesystem DAX is associated with ablock_device for now, but perhaps directly to a dax device in thefuture, or for new pmem-only filesystems.[1]: https://lkml.org/lkml/2017/1/19/880Suggested-by: Christoph Hellwig Signed-off-by: Dan Williams List of files: /linux-6.15/drivers/dax/Kconfig