android_kernel_samsung_sm8650_ksu/drivers/nvdimm/Kconfig

# SPDX-License-Identifier: GPL-2.0-only
menuconfig LIBNVDIMM
	tristate "NVDIMM (Non-Volatile Memory Device) Support"
	depends on PHYS_ADDR_T_64BIT
	depends on HAS_IOMEM
	depends on BLK_DEV
	select MEMREGION
	help
	  Generic support for non-volatile memory devices including
	  ACPI-6-NFIT defined resources.  On platforms that define an
	  NFIT, or otherwise can discover NVDIMM resources, a libnvdimm
	  bus is registered to advertise PMEM (persistent memory)
	  namespaces (/dev/pmemX). A PMEM namespace refers to a
	  memory resource that may span multiple DIMMs and support DAX
	  (see CONFIG_DAX).

if LIBNVDIMM

config BLK_DEV_PMEM
	tristate "PMEM: Persistent memory block device support"
	default LIBNVDIMM
	select DAX
	select ND_BTT if BTT
	select ND_PFN if NVDIMM_PFN
	help
	  Memory ranges for PMEM are described by either an NFIT
	  (NVDIMM Firmware Interface Table, see CONFIG_NFIT_ACPI), a
	  non-standard OEM-specific E820 memory type (type-12, see
	  CONFIG_X86_PMEM_LEGACY), or it is manually specified by the
	  'memmap=nn[KMG]!ss[KMG]' kernel command line (see
	  Documentation/admin-guide/kernel-parameters.rst).  This driver converts
	  these persistent memory ranges into block devices that are
	  capable of DAX (direct-access) file system mappings.  See
	  Documentation/driver-api/nvdimm/nvdimm.rst for more details.

	  Say Y if you want to use an NVDIMM

config ND_CLAIM
	bool

config ND_BTT
	tristate

config BTT
	bool "BTT: Block Translation Table (atomic sector updates)"
	default y if LIBNVDIMM
	select ND_CLAIM
	help
	  The Block Translation Table (BTT) provides atomic sector
	  update semantics for persistent memory devices, so that
	  applications that rely on sector writes not being torn (a
	  guarantee that typical disks provide) can continue to do so.
	  The BTT manifests itself as an alternate personality for an
	  NVDIMM namespace, i.e. a namespace can be in raw mode pmemX,
	  or 'sectored' mode.

	  Select Y if unsure

config ND_PFN
	tristate

config NVDIMM_PFN
	bool "PFN: Map persistent (device) memory"
	default LIBNVDIMM
	depends on ZONE_DEVICE
	select ND_CLAIM
	help
	  Map persistent memory, i.e. advertise it to the memory
	  management sub-system.  By default persistent memory does
	  not support direct I/O, RDMA, or any other usage that
	  requires a 'struct page' to mediate an I/O request.  This
	  driver allocates and initializes the infrastructure needed
	  to support those use cases.

	  Select Y if unsure

config NVDIMM_DAX
	bool "NVDIMM DAX: Raw access to persistent memory"
	default LIBNVDIMM
	depends on NVDIMM_PFN
	help
	  Support raw device dax access to a persistent memory
	  namespace.  For environments that want to hard partition
	  persistent memory, this capability provides a mechanism to
	  sub-divide a namespace into character devices that can only be
	  accessed via DAX (mmap(2)).

	  Select Y if unsure

config OF_PMEM
	tristate "Device-tree support for persistent memory regions"
	depends on OF
	default LIBNVDIMM
	help
	  Allows regions of persistent memory to be described in the
	  device-tree.

	  Select Y if unsure.

config NVDIMM_KEYS
	def_bool y
	depends on ENCRYPTED_KEYS
	depends on (LIBNVDIMM=ENCRYPTED_KEYS) || LIBNVDIMM=m

config NVDIMM_KMSAN
	bool
	depends on KMSAN
	help
	  KMSAN, and other memory debug facilities, increase the size of
	  'struct page' to contain extra metadata. This collides with
	  the NVDIMM capability to store a potentially
	  larger-than-"System RAM" size 'struct page' array in a
	  reservation of persistent memory rather than limited /
	  precious DRAM. However, that reservation needs to persist for
	  the life of the given NVDIMM namespace. If you are using KMSAN
	  to debug an issue unrelated to NVDIMMs or DAX then say N to this
	  option. Otherwise, say Y but understand that any namespaces
	  (with the page array stored pmem) created with this build of
	  the kernel will permanently reserve and strand excess
	  capacity compared to the CONFIG_KMSAN=n case.

	  Select N if unsure.

config NVDIMM_TEST_BUILD
	tristate "Build the unit test core"
	depends on m
	depends on COMPILE_TEST && X86_64
	default m if COMPILE_TEST
	help
	  Build the core of the unit test infrastructure. The result of
	  this build is non-functional for unit test execution, but it
	  otherwise helps catch build errors induced by changes to the
	  core devm_memremap_pages() implementation and other
	  infrastructure.

endif