mirror of
https://github.com/torvalds/linux.git
synced 2024-12-13 22:53:20 +00:00
4e65e9381c
The function dax_pmem_probe() in drivers/dax/pmem.c is compiled under the CONFIG_DEV_DAX_PMEM tri-state config option. This config option currently only depends on CONFIG_NVDIMM_DAX, a bool, which means that the following configuration is possible: CONFIG_LIBNVDIMM=m ... CONFIG_NVDIMM_DAX=y CONFIG_DEV_DAX=y CONFIG_DEV_DAX_PMEM=y With this config LIBNVDIMM is compiled as a module with NVDIMM_DAX=y just meaning that we will compile drivers/nvdimm/dax_devs.c into that module. However, dax_pmem_probe() depends on several symbols defined in drivers/nvdimm/dax_devs.c, which results in the following build errors: drivers/built-in.o: In function `dax_pmem_probe': linux/drivers/dax/pmem.c:70: undefined reference to `to_nd_dax' linux/drivers/dax/pmem.c:74: undefined reference to `nvdimm_namespace_common_probe' linux/drivers/dax/pmem.c:80: undefined reference to `devm_nsio_enable' linux/drivers/dax/pmem.c:81: undefined reference to `nvdimm_setup_pfn' linux/drivers/dax/pmem.c:84: undefined reference to `devm_nsio_disable' linux/drivers/dax/pmem.c:122: undefined reference to `to_nd_region' drivers/built-in.o: In function `dax_pmem_init': linux/drivers/dax/pmem.c:147: undefined reference to `__nd_driver_register' Fix this by making NVDIMM_DAX a tristate. DEV_DAX_PMEM depends on NVDIMM_DAX which depends on LIBNVDIMM. Since they are all now tristates, if LIBNVDIMM is built as a kernel module DEV_DAX_PMEM will be as well. This prevents dax_devs.c from being built as a built-in while its dependencies are in the libnvdimm.ko module. Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
105 lines
3.4 KiB
Plaintext
105 lines
3.4 KiB
Plaintext
menuconfig LIBNVDIMM
|
|
tristate "NVDIMM (Non-Volatile Memory Device) Support"
|
|
depends on PHYS_ADDR_T_64BIT
|
|
depends on HAS_IOMEM
|
|
depends on BLK_DEV
|
|
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) and BLK (sliding mmio window(s))
|
|
namespaces (/dev/ndblkX.Y). A PMEM namespace refers to a
|
|
memory resource that may span multiple DIMMs and support DAX
|
|
(see CONFIG_DAX). A BLK namespace refers to an NVDIMM control
|
|
region which exposes an mmio register set for windowed access
|
|
mode to non-volatile memory.
|
|
|
|
if LIBNVDIMM
|
|
|
|
config BLK_DEV_PMEM
|
|
tristate "PMEM: Persistent memory block device support"
|
|
default LIBNVDIMM
|
|
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/kernel-parameters.txt). This driver converts
|
|
these persistent memory ranges into block devices that are
|
|
capable of DAX (direct-access) file system mappings. See
|
|
Documentation/nvdimm/nvdimm.txt for more details.
|
|
|
|
Say Y if you want to use an NVDIMM
|
|
|
|
config ND_BLK
|
|
tristate "BLK: Block data window (aperture) device support"
|
|
default LIBNVDIMM
|
|
select ND_BTT if BTT
|
|
help
|
|
Support NVDIMMs, or other devices, that implement a BLK-mode
|
|
access capability. BLK-mode access uses memory-mapped-i/o
|
|
apertures to access persistent media.
|
|
|
|
Say Y if your platform firmware emits an ACPI.NFIT table
|
|
(CONFIG_ACPI_NFIT), or otherwise exposes BLK-mode
|
|
capabilities.
|
|
|
|
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,
|
|
ndblkX.Y, etc...), or 'sectored' mode, (pmemXs, ndblkX.Ys,
|
|
etc...).
|
|
|
|
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
|
|
tristate "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
|
|
peristent 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
|
|
|
|
endif
|