xref: /OK3568_Linux_fs/kernel/Documentation/nvdimm/maintainer-entry-profile.rst (revision 4882a59341e53eb6f0b4789bf948001014eff981)
1*4882a593SmuzhiyunLIBNVDIMM Maintainer Entry Profile
2*4882a593Smuzhiyun==================================
3*4882a593Smuzhiyun
4*4882a593SmuzhiyunOverview
5*4882a593Smuzhiyun--------
6*4882a593SmuzhiyunThe libnvdimm subsystem manages persistent memory across multiple
7*4882a593Smuzhiyunarchitectures. The mailing list is tracked by patchwork here:
8*4882a593Smuzhiyunhttps://patchwork.kernel.org/project/linux-nvdimm/list/
9*4882a593Smuzhiyun...and that instance is configured to give feedback to submitters on
10*4882a593Smuzhiyunpatch acceptance and upstream merge. Patches are merged to either the
11*4882a593Smuzhiyun'libnvdimm-fixes' or 'libnvdimm-for-next' branch. Those branches are
12*4882a593Smuzhiyunavailable here:
13*4882a593Smuzhiyunhttps://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm.git/
14*4882a593Smuzhiyun
15*4882a593SmuzhiyunIn general patches can be submitted against the latest -rc; however, if
16*4882a593Smuzhiyunthe incoming code change is dependent on other pending changes then the
17*4882a593Smuzhiyunpatch should be based on the libnvdimm-for-next branch. However, since
18*4882a593Smuzhiyunpersistent memory sits at the intersection of storage and memory there
19*4882a593Smuzhiyunare cases where patches are more suitable to be merged through a
20*4882a593SmuzhiyunFilesystem or the Memory Management tree. When in doubt copy the nvdimm
21*4882a593Smuzhiyunlist and the maintainers will help route.
22*4882a593Smuzhiyun
23*4882a593SmuzhiyunSubmissions will be exposed to the kbuild robot for compile regression
24*4882a593Smuzhiyuntesting. It helps to get a success notification from that infrastructure
25*4882a593Smuzhiyunbefore submitting, but it is not required.
26*4882a593Smuzhiyun
27*4882a593Smuzhiyun
28*4882a593SmuzhiyunSubmit Checklist Addendum
29*4882a593Smuzhiyun-------------------------
30*4882a593SmuzhiyunThere are unit tests for the subsystem via the ndctl utility:
31*4882a593Smuzhiyunhttps://github.com/pmem/ndctl
32*4882a593SmuzhiyunThose tests need to be passed before the patches go upstream, but not
33*4882a593Smuzhiyunnecessarily before initial posting. Contact the list if you need help
34*4882a593Smuzhiyungetting the test environment set up.
35*4882a593Smuzhiyun
36*4882a593SmuzhiyunACPI Device Specific Methods (_DSM)
37*4882a593Smuzhiyun~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
38*4882a593SmuzhiyunBefore patches enabling a new _DSM family will be considered, it must
39*4882a593Smuzhiyunbe assigned a format-interface-code from the NVDIMM Sub-team of the ACPI
40*4882a593SmuzhiyunSpecification Working Group. In general, the stance of the subsystem is
41*4882a593Smuzhiyunto push back on the proliferation of NVDIMM command sets, so do strongly
42*4882a593Smuzhiyunconsider implementing support for an existing command set. See
43*4882a593Smuzhiyundrivers/acpi/nfit/nfit.h for the set of supported command sets.
44*4882a593Smuzhiyun
45*4882a593Smuzhiyun
46*4882a593SmuzhiyunKey Cycle Dates
47*4882a593Smuzhiyun---------------
48*4882a593SmuzhiyunNew submissions can be sent at any time, but if they intend to hit the
49*4882a593Smuzhiyunnext merge window they should be sent before -rc4, and ideally
50*4882a593Smuzhiyunstabilized in the libnvdimm-for-next branch by -rc6. Of course if a
51*4882a593Smuzhiyunpatch set requires more than 2 weeks of review, -rc4 is already too late
52*4882a593Smuzhiyunand some patches may require multiple development cycles to review.
53*4882a593Smuzhiyun
54*4882a593Smuzhiyun
55*4882a593SmuzhiyunReview Cadence
56*4882a593Smuzhiyun--------------
57*4882a593SmuzhiyunIn general, please wait up to one week before pinging for feedback. A
58*4882a593Smuzhiyunprivate mail reminder is preferred. Alternatively ask for other
59*4882a593Smuzhiyundevelopers that have Reviewed-by tags for libnvdimm changes to take a
60*4882a593Smuzhiyunlook and offer their opinion.
61