Changes in Makefile

de7a9e94 - drivers/nvdimm: Fix build failure when CONFIG_PERF_EVENTS is not set

Wed, 23 Mar 2022 16:45:49 +0000

drivers/nvdimm: Fix build failure when CONFIG_PERF_EVENTS is not setThe following build failure occurs when CONFIG_PERF_EVENTS is not setas generic pmu functions are not visible in that scenario.|-- s390-randconfig-r044-20220313| |-- nd_perf.c:(.text):undefined-reference-to-perf_pmu_migrate_context| |-- nd_perf.c:(.text):undefined-reference-to-perf_pmu_register| `-- nd_perf.c:(.text):undefined-reference-to-perf_pmu_unregisterSimilar build failure in nds32 architecture:nd_perf.c:(.text+0x21e): undefined reference to `perf_pmu_migrate_context'nd_perf.c:(.text+0x434): undefined reference to `perf_pmu_register'nd_perf.c:(.text+0x57c): undefined reference to `perf_pmu_unregister'Fix this issue by adding check for CONFIG_PERF_EVENTS config optionand disabling the nvdimm perf interface incase this config is not set.Also remove function declaration of perf_pmu_migrate_context,perf_pmu_register, perf_pmu_unregister functions from nd.h as these arecommon pmu functions which are part of perf_event.h and since weare disabling nvdimm perf interface incase CONFIG_PERF_EVENTS optionis not set, we not need to declare them in nd.hAlso move the platform_device header file addition part from nd.h tond_perf.c and add stub functions for register_nvdimm_pmu andunregister_nvdimm_pmu functions to handle CONFIG_PERF_EVENTS=ncase.Fixes: 0fab1ba6ad6b ("drivers/nvdimm: Add perf interface to expose nvdimm performance stats") (Commit id based on libnvdimm-for-next tree)Signed-off-by: Kajol Jain Link: https://lore.kernel.org/all/62317124.YBQFU33+s%2FwdvWGj%25lkp@intel.com/Reported-by: kernel test robot Link: https://lore.kernel.org/r/20220323164550.109768-1-kjain@linux.ibm.comSigned-off-by: Dan Williams List of files: /linux-6.15/drivers/nvdimm/Makefile

f8669f1d - nvdimm/blk: Delete the block-aperture window driver

Thu, 10 Mar 2022 03:49:26 +0000

nvdimm/blk: Delete the block-aperture window driverBlock Aperture Window support was an attempt to layer an error modelover PMEM for platforms that did not support machine-check-recovery.However, it was abandoned before it ever shipped, and only ever existedin the ACPI specification. Meanwhile Linux has carried a large pile ofdead code for non-shipping infrastructure. For years it has been off tothe side out of the way, but now CXL and recent directions with DAXsupport have the potential to collide with this code.In preparation for adding discontiguous namespace support, apre-requisite for the nvdimm subsystem to replace device-mapper forstriping + concatenation use cases, delete BLK aperture support.On the obscure chance that some hardware vendor shipped support for thismode, note that the driver will still keep BLK space reserved in thelabel area. So an end user in this case would still have the opportunityto report the regression to get BLK-mode support restored withoutrisking the data they have on that device.Reviewed-by: Christoph Hellwig Link: https://lore.kernel.org/r/164688416668.2879318.16903178375774275120.stgit@dwillia2-desk3.amr.corp.intel.comSigned-off-by: Dan Williams List of files: /linux-6.15/drivers/nvdimm/Makefile

0fab1ba6 - drivers/nvdimm: Add perf interface to expose nvdimm performance stats

Fri, 25 Feb 2022 14:30:22 +0000

drivers/nvdimm: Add perf interface to expose nvdimm performance statsA common interface is added to get performance stats reportingsupport for nvdimm devices. Added interface defines supportedevent list, config fields for the event attributes and theircorresponding bit values which are exported via sysfs.Interface also added support for pmu register/unregister functions,cpu hotplug feature along with macros for handling events additionvia sysfs. It adds attribute groups for format, cpumask and eventsto the pmu structure.User could use the standard perf tool to access perf events exposedvia nvdimm pmu.[Declare pmu functions in nd.h file to resolve implicit-function-declarationwarning and make hotplug function static as reported by kernel test robot]Acked-by: Peter Zijlstra (Intel) Tested-by: Nageswara R Sastry Signed-off-by: Kajol Jain Link: https://lore.kernel.org/all/202202241242.zqzGkguy-lkp@intel.com/Reported-by: kernel test robot Reviewed-by: Madhavan Srinivasan Link: https://lore.kernel.org/r/20220225143024.47947-3-kjain@linux.ibm.comSigned-off-by: Dan Williams List of files: /linux-6.15/drivers/nvdimm/Makefile

62974fc3 - libnvdimm: Enable unit test infrastructure compile checks

Wed, 04 Sep 2019 22:43:31 +0000

libnvdimm: Enable unit test infrastructure compile checksThe infrastructure to mock core libnvdimm routines for unit testingpurposes is prone to bitrot relative to refactoring of that core. Arrangefor the unit test core to be built when CONFIG_COMPILE_TEST=y. This doesnot result in a functional unit test environment, it is only a helper for0day to catch unit test build regressions.Note that there are a few x86isms in the implementation, so this does notbother compile testing this architectures other than 64-bit x86.Link: https://lore.kernel.org/r/156763690875.2556198.15786177395425033830.stgit@dwillia2-desk3.amr.corp.intel.comReported-by: Christoph Hellwig Signed-off-by: Dan Williams Signed-off-by: Jason Gunthorpe List of files: /linux-6.15/drivers/nvdimm/Makefile

6e84200c - virtio-pmem: Add virtio pmem driver

Fri, 05 Jul 2019 14:03:23 +0000

virtio-pmem: Add virtio pmem driverThis patch adds virtio-pmem driver for KVM guest.Guest reads the persistent memory range information fromQemu over VIRTIO and registers it on nvdimm_bus. It alsocreates a nd_region object with the persistent memoryrange information so that existing 'nvdimm/pmem' drivercan reserve this into system memory map. This way'virtio-pmem' driver uses existing functionality of pmemdriver to register persistent memory compatible for DAXcapable filesystems.This also provides function to perform guest flush overVIRTIO from 'pmem' driver when userspace performs flushon DAX memory range.Signed-off-by: Pankaj Gupta Reviewed-by: Yuval Shaia Acked-by: Michael S. Tsirkin Acked-by: Jakub Staron Tested-by: Jakub Staron Reviewed-by: Cornelia Huck Signed-off-by: Dan Williams List of files: /linux-6.15/drivers/nvdimm/Makefile

4c6926a2 - acpi/nfit, libnvdimm: Add unlock of nvdimm support for Intel DIMMs

Thu, 06 Dec 2018 20:40:01 +0000

acpi/nfit, libnvdimm: Add unlock of nvdimm support for Intel DIMMsAdd support to unlock the dimm via the kernel key management APIs. Thepassphrase is expected to be pulled from userspace through keyutils.The key management and sysfs attributes are libnvdimm generic.Encrypted keys are used to protect the nvdimm passphrase at rest. Themaster key can be a trusted-key sealed in a TPM, preferred, or anencrypted-key, more flexible, but more exposure to a potential attacker.Signed-off-by: Dave Jiang Co-developed-by: Dan Williams Reported-by: Randy Dunlap Signed-off-by: Dan Williams List of files: /linux-6.15/drivers/nvdimm/Makefile

71719760 - libnvdimm: Add device-tree based driver

Fri, 06 Apr 2018 05:21:14 +0000

libnvdimm: Add device-tree based driverThis patch adds peliminary device-tree bindings for persistent memoryregions. The driver registers a libnvdimm bus for each pmem-regionnode and each address range under the node is converted to a regionwithin that bus.Signed-off-by: Oliver O'Halloran Signed-off-by: Dan Williams List of files: /linux-6.15/drivers/nvdimm/Makefile

aa9ad44a - libnvdimm: move poison list functions to a new 'badrange' file

Wed, 23 Aug 2017 19:48:26 +0000

libnvdimm: move poison list functions to a new 'badrange' filenfit_test needs to use the poison list manipulation code as well. Makeit more generic and in the process rename poison to badrange, and moveall the related helpers to a new file.Signed-off-by: Dave Jiang [vishal: Add badrange.o to nfit_test's Kbuild][vishal: add a missed include in bus.c for the new badrange functions][vishal: rename all instances of 'be' to 'bre']Signed-off-by: Vishal Verma Signed-off-by: Dan Williams List of files: /linux-6.15/drivers/nvdimm/Makefile

b2441318 - License cleanup: add SPDX GPL-2.0 license identifier to files with no license

Wed, 01 Nov 2017 14:07:57 +0000

License cleanup: add SPDX GPL-2.0 license identifier to files with no licenseMany source files in the tree are missing licensing information, whichmakes it harder for compliance tools to determine the correct license.By default all files without license information are under the defaultlicense of the kernel, which is GPL version 2.Update the files which contain no license information with the 'GPL-2.0'SPDX license identifier. The SPDX identifier is a legally bindingshorthand, which can be used instead of the full boiler plate text.This patch is based on work done by Thomas Gleixner and Kate Stewart andPhilippe Ombredanne.How this work was done:Patches were generated and checked against linux-4.14-rc6 for a subset ofthe use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information,Further patches will be generated in subsequent months to fix up caseswhere non-standard license headers were used, and references to licensehad to be inferred by heuristics based on keywords.The analysis to determine which SPDX License Identifier to be applied toa file was done in a spreadsheet of side by side results from of theoutput of two independent scanners (ScanCode & Windriver) producing SPDXtag:value files created by Philippe Ombredanne. Philippe prepared thebase worksheet, and did an initial spot review of a few 1000 files.The 4.13 kernel was the starting point of the analysis with 60,537 filesassessed. Kate Stewart did a file by file comparison of the scannerresults in the spreadsheet to determine which SPDX license identifier(s)to be applied to the file. She confirmed any determination that was notimmediately clear with lawyers working with the Linux Foundation.Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines).All documentation files were explicitly excluded.The following heuristics were used to determine which SPDX licenseidentifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time.In total, over 70 hours of logged manual review was done on thespreadsheet to determine the SPDX license identifiers to apply to thesource files by Kate, Philippe, Thomas and, in some cases, confirmationby lawyers working with the Linux Foundation.Kate also obtained a third independent scan of the 4.13 code base fromFOSSology, and compared selected files where the other two scannersdisagreed against that SPDX file, to see if there was new insights. TheWindriver scanner is based on an older version of FOSSology in part, sothey are related.Thomas did random spot checks in about 500 files from the spreadsheetsfor the uapi headers and agreed with SPDX license identifier in thefiles he inspected. For the non-uapi files Thomas did random spot checksin about 15000 files.In initial set of patches against 4.14-rc6, 3 files were found to havecopy/paste license identifier errors, and have been fixed to reflect thecorrect identifier.Additionally Philippe spent 10 hours this week doing a detailed manualinspection and review of the 12,461 patched files from the initial patchversion early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correctThis produced a worksheet with 20 files needing minor correction. Thisworksheet was then exported into 3 different .csv files for thedifferent types of files to be modified.These .csv files were then reviewed by Greg. Thomas wrote a script toparse the csv files and add the proper SPDX tag to the file, in theformat that the file expected. This script was further refined by Gregbased on the output to detect more types of files automatically and todistinguish between header and source .c files (which need differentcomment types.) Finally Greg ran the script using the .csv files togenerate the patches.Reviewed-by: Kate Stewart Reviewed-by: Philippe Ombredanne Reviewed-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman List of files: /linux-6.15/drivers/nvdimm/Makefile

cd03412a - libnvdimm, dax: introduce device-dax infrastructure

Fri, 11 Mar 2016 18:15:36 +0000

libnvdimm, dax: introduce device-dax infrastructureDevice DAX is the device-centric analogue of Filesystem DAX(CONFIG_FS_DAX). It allows persistent memory ranges to be allocated andmapped without need of an intervening file system. This initialinfrastructure arranges for a libnvdimm pfn-device to be represented asa different device-type so that it can be attached to a driver otherthan the pmem driver.Signed-off-by: Dan Williams List of files: /linux-6.15/drivers/nvdimm/Makefile

e1455744 - libnvdimm, pfn: 'struct page' provider infrastructure

Thu, 30 Jul 2015 21:57:47 +0000

libnvdimm, pfn: 'struct page' provider infrastructureImplement the base infrastructure for libnvdimm PFN devices. Similar toBTT devices they take a namespace as a backing device and layerfunctionality on top. In this case the functionality is reserving spacefor an array of 'struct page' entries to be handed out throughpfn_to_page(). For now this is just the basic libnvdimm-device-model forconfiguring the base PFN device.As the namespace claiming mechanism for PFN devices is mostly identicalto BTT devices drivers/nvdimm/claim.c is created to house the commonbits.Cc: Ross Zwisler Signed-off-by: Dan Williams List of files: /linux-6.15/drivers/nvdimm/Makefile

7a67832c - libnvdimm, e820: make CONFIG_X86_PMEM_LEGACY a tristate option

Wed, 19 Aug 2015 04:34:34 +0000

libnvdimm, e820: make CONFIG_X86_PMEM_LEGACY a tristate optionWe currently register a platform device for e820 type-12 memory andregister a nvdimm bus beneath it. Registering the platform devicetriggers the device-core machinery to probe for a driver, but thatsearch currently comes up empty. Building the nvdimm-bus registrationinto the e820_pmem platform device registration in this way forceslibnvdimm to be built-in. Instead, convert the built-in portion ofCONFIG_X86_PMEM_LEGACY to simply register a platform device and move therest of the logic to the driver for e820_pmem, for the followingreasons:1/ Letting e820_pmem support be a module allows building and testing libnvdimm.ko changes without rebooting2/ All the normal policy around modules can be applied to e820_pmem (unbind to disable and/or blacklisting the module from loading by default)3/ Moving the driver to a generic location and converting it to scan "iomem_resource" rather than "e820.map" means any other architecture can take advantage of this simple nvdimm resource discovery mechanism by registering a resource named "Persistent Memory (legacy)"Cc: Christoph Hellwig Signed-off-by: Dan Williams List of files: /linux-6.15/drivers/nvdimm/Makefile

047fc8a1 - libnvdimm, nfit, nd_blk: driver for BLK-mode access persistent memory

Thu, 25 Jun 2015 08:21:02 +0000

libnvdimm, nfit, nd_blk: driver for BLK-mode access persistent memoryThe libnvdimm implementation handles allocating dimm address space (DPA)between PMEM and BLK mode interfaces. After DPA has been allocated froma BLK-region to a BLK-namespace the nd_blk driver attaches to handle I/Oas a struct bio based block device. Unlike PMEM, BLK is required tohandle platform specific details like mmio register formats and memorycontroller interleave. For this reason the libnvdimm generic nd_blkdriver calls back into the bus provider to carry out the I/O.This initial implementation handles the BLK interface defined by theACPI 6 NFIT [1] and the NVDIMM DSM Interface Example [2] composed fromDCR (dimm control region), BDW (block data window), IDT (interleavedescriptor) NFIT structures and the hardware register format.[1]: http://www.uefi.org/sites/default/files/resources/ACPI_6.0.pdf[2]: http://pmem.io/documents/NVDIMM_DSM_Interface_Example.pdfCc: Andy Lutomirski Cc: Boaz Harrosh Cc: H. Peter Anvin Cc: Jens Axboe Cc: Ingo Molnar Cc: Christoph Hellwig Signed-off-by: Ross Zwisler Acked-by: Rafael J. Wysocki Signed-off-by: Dan Williams List of files: /linux-6.15/drivers/nvdimm/Makefile

5212e11f - nd_btt: atomic sector updates

Thu, 25 Jun 2015 08:20:32 +0000

nd_btt: atomic sector updatesBTT stands for Block Translation Table, and is a way to provide powerfail sector atomicity semantics for block devices that have the abilityto perform byte granularity IO. It relies on the capability of libnvdimmnamespace devices to do byte aligned IO.The BTT works as a stacked blocked device, and reserves a chunk of spacefrom the backing device for its accounting metadata. It is a bio-baseddriver because all IO is done synchronously, and there is no queuing orasynchronous completions at either the device or the driver level.The BTT uses 'lanes' to index into various 'on-disk' data structures,and lanes also act as a synchronization mechanism in case there are moreCPUs than available lanes. We did a comparison between two lane lockstrategies - first where we kept an atomic counter around that trackedwhich was the last lane that was used, and 'our' lane was determined byatomically incrementing that. That way, for the nr_cpus > nr_lanes case,theoretically, no CPU would be blocked waiting for a lane. The otherstrategy was to use the cpu number we're scheduled on to and hash it toa lane number. Theoretically, this could block an IO that could'veotherwise run using a different, free lane. But some fio workloadsshowed that the direct cpu -> lane hash performed faster than tracking'last lane' - my reasoning is the cache thrash caused by moving theatomic variable made that approach slower than simply waiting out thein-progress IO. This supports the conclusion that the driver can be avery simple bio-based one that does synchronous IOs instead of queuing.Cc: Andy Lutomirski Cc: Boaz Harrosh Cc: H. Peter Anvin Cc: Jens Axboe Cc: Ingo Molnar Cc: Christoph Hellwig Cc: Neil Brown Cc: Jeff Moyer Cc: Dave Chinner Cc: Greg KH [jmoyer: fix nmi watchdog timeout in btt_map_init][jmoyer: move btt initialization to module load path][jmoyer: fix memory leak in the btt initialization path][jmoyer: Don't overwrite corrupted arenas]Signed-off-by: Vishal Verma Signed-off-by: Dan Williams List of files: /linux-6.15/drivers/nvdimm/Makefile

8c2f7e86 - libnvdimm: infrastructure for btt devices

Thu, 25 Jun 2015 08:20:04 +0000

libnvdimm: infrastructure for btt devicesNVDIMM namespaces, in addition to accepting "struct bio" based requests,also have the capability to perform byte-aligned accesses. By defaultonly the bio/block interface is used. However, if another driver canmake effective use of the byte-aligned capability it can claim namespaceinterface and use the byte-aligned ->rw_bytes() interface.The BTT driver is the initial first consumer of this mechanism to allowadding atomic sector update semantics to a pmem or blk namespace. Thispatch is the sysfs infrastructure to allow configuring a BTT instancefor a namespace. Enabling that BTT and performing i/o is in asubsequent patch.Cc: Greg KH Cc: Neil Brown Signed-off-by: Dan Williams List of files: /linux-6.15/drivers/nvdimm/Makefile

4a826c83 - libnvdimm: namespace indices: read and validate

Tue, 09 Jun 2015 20:09:36 +0000

libnvdimm: namespace indices: read and validateThis on media label format [1] consists of two index blocks followed byan array of labels. None of these structures are ever updated in place.A sequence number tracks the current active index and the next one towrite, while labels are written to free slots. +------------+ | | | nsindex0 | | | +------------+ | | | nsindex1 | | | +------------+ | label0 | +------------+ | label1 | +------------+ | | ....nslot... | | +------------+ | labelN | +------------+After reading valid labels, store the dpa ranges they claim intoper-dimm resource trees.[1]: http://pmem.io/documents/NVDIMM_Namespace_Spec.pdfCc: Neil Brown Acked-by: Christoph Hellwig Signed-off-by: Dan Williams List of files: /linux-6.15/drivers/nvdimm/Makefile

18da2c9e - libnvdimm, pmem: move pmem to drivers/nvdimm/

Tue, 09 Jun 2015 18:13:37 +0000

libnvdimm, pmem: move pmem to drivers/nvdimm/Prepare the pmem driver to consume PMEM namespaces emitted by regions ofan nvdimm_bus instance. No functional change.Acked-by: Christoph Hellwig Tested-by: Toshi Kani Signed-off-by: Dan Williams List of files: /linux-6.15/drivers/nvdimm/Makefile

3d88002e - libnvdimm: support for legacy (non-aliasing) nvdimms

Sun, 31 May 2015 19:02:11 +0000

libnvdimm: support for legacy (non-aliasing) nvdimmsThe libnvdimm region driver is an intermediary driver that translatesnon-volatile "region"s into "namespace" sub-devices that are surfaced bypersistent memory block-device drivers (PMEM and BLK).ACPI 6 introduces the concept that a given nvdimm may simultaneouslyoffer multiple access modes to its media through direct PMEM load/storeaccess, or windowed BLK mode. Existing nvdimms mostly implement a PMEMinterface, some offer a BLK-like mode, but never both as ACPI 6 defines.If an nvdimm is single interfaced, then there is no need for dimmmetadata labels. For these devices we can take the region boundariesdirectly to create a child namespace device (nd_namespace_io).Acked-by: Christoph Hellwig Tested-by: Toshi Kani Signed-off-by: Dan Williams List of files: /linux-6.15/drivers/nvdimm/Makefile

1f7df6f8 - libnvdimm, nfit: regions (block-data-window, persistent memory, volatile memory)

Wed, 10 Jun 2015 00:13:14 +0000

libnvdimm, nfit: regions (block-data-window, persistent memory, volatile memory)A "region" device represents the maximum capacity of a BLK range (mmioblock-data-window(s)), or a PMEM range (DAX-capable persistent memory orvolatile memory), without regard for aliasing. Aliasing, in thedimm-local address space (DPA), is resolved by metadata on a dimm todesignate which exclusive interface will access the aliased DPA ranges.Support for the per-dimm metadata/label arrvies is in a subsequentpatch.The name format of "region" devices is "regionN" where, like dimms, N isa global ida index assigned at discovery time. This id is not reliableacross reboots nor in the presence of hotplug. Look to attributes ofthe region or static id-data of the sub-namespace to generate apersistent name. However, if the platform configuration does not changeit is reasonable to expect the same region id to be assigned at the nextboot."region"s have 2 generic attributes "size", and "mapping"s where:- size: the BLK accessible capacity or the span of the system physical address range in the case of PMEM.- mappingN: a tuple describing a dimm's contribution to the region's capacity in the format (,,). For a PMEM-region there will be at least one mapping per dimm in the interleave set. For a BLK-region there is only "mapping0" listing the starting DPA of the BLK-region and the available DPA capacity of that space (matches "size" above).The max number of mappings per "region" is hard coded per theconstraints of sysfs attribute groups. That said the number of mappingsper region should never exceed the maximum number of possible dimms inthe system. If the current number turns out to not be enough then the"mappings" attribute clarifies how many there are supposed to be. "32should be enough for anybody...".Cc: Neil Brown Cc: Cc: Greg KH Cc: Robert Moore Cc: Rafael J. Wysocki Acked-by: Christoph Hellwig Acked-by: Rafael J. Wysocki Tested-by: Toshi Kani Signed-off-by: Dan Williams List of files: /linux-6.15/drivers/nvdimm/Makefile

4d88a97a - libnvdimm, nvdimm: dimm driver and base libnvdimm device-driver infrastructure

Sun, 31 May 2015 18:41:48 +0000

libnvdimm, nvdimm: dimm driver and base libnvdimm device-driver infrastructure* Implement the device-model infrastructure for loading modules and attaching drivers to nvdimm devices. This is a simple association of a nd-device-type number with a driver that has a bitmask of supported device types. To facilitate userspace bind/unbind operations 'modalias' and 'devtype', that also appear in the uevent, are added as generic sysfs attributes for all nvdimm devices. The reason for the device-type number is to support sub-types within a given parent devtype, be it a vendor-specific sub-type or otherwise.* The first consumer of this infrastructure is the driver for dimm devices. It simply uses control messages to retrieve and store the configuration-data image (label set) from each dimm.Note: nd_device_register() arranges for asynchronous registration of nvdimm bus devices by default.Cc: Greg KH Cc: Neil Brown Acked-by: Christoph Hellwig Tested-by: Toshi Kani Signed-off-by: Dan Williams List of files: /linux-6.15/drivers/nvdimm/Makefile