On Fri, 2020-10-09 at 17:30 +0530, Vaibhav Jain wrote: > commit 107a24ff429f ("ndctl/list: Add firmware activation > enumeration") introduced changes in add_dimm() to enumerate the status > of firmware activation. However a branch added in that commit broke > the probe for non-nfit nvdimms like one provided by papr-scm. This > cause an error reported when listing namespaces like below: > > $ sudo ndctl list > libndctl: add_dimm: nmem0: probe failed: No such device > libndctl: __sysfs_device_parse: nmem0: add_dev() failed > > Do a fix for this by removing the offending branch in the add_dimm() > patch. This continues the flow of add_dimm() probe even if the nfit is > not detected on the associated bus. > > Fixes: 107a24ff429fa("ndctl/list: Add firmware activation enumeration") > Signed-off-by: Vaibhav Jain <vaibhav(a)linux.ibm.com&gt; > --- > ndctl/lib/libndctl.c | 3 --- > 1 file changed, 3 deletions(-) Ah apologies - this snuck in when I reflowed Dan's patches on top of the papr work for v70. I expect you'd like a point release with this fix asap? Is there a way for me to incorporate some papr unit tests into my release workflow so I can avoid breaking things like this again? I'll also try to do a better job of pushing things out to the pending branch more frequently so if you're monitoring that branch, hopefully things like this will get caught before a release happens :)

Hi Dan and Vishal, Thanks so much for quick turnaround on this. Dan Williams <dan.j.williams(a)intel.com&gt; writes: > On Fri, Oct 9, 2020 at 11:36 AM Verma, Vishal L > <vishal.l.verma(a)intel.com&gt; wrote: >> >> On Fri, 2020-10-09 at 17:30 +0530, Vaibhav Jain wrote: >> > commit 107a24ff429f ("ndctl/list: Add firmware activation >> > enumeration") introduced changes in add_dimm() to enumerate the status >> > of firmware activation. However a branch added in that commit broke >> > the probe for non-nfit nvdimms like one provided by papr-scm. This >> > cause an error reported when listing namespaces like below: >> > >> > $ sudo ndctl list >> > libndctl: add_dimm: nmem0: probe failed: No such device >> > libndctl: __sysfs_device_parse: nmem0: add_dev() failed >> > >> > Do a fix for this by removing the offending branch in the add_dimm() >> > patch. This continues the flow of add_dimm() probe even if the nfit is >> > not detected on the associated bus. >> > >> > Fixes: 107a24ff429fa("ndctl/list: Add firmware activation enumeration") >> > Signed-off-by: Vaibhav Jain <vaibhav(a)linux.ibm.com&gt; >> > --- >> > ndctl/lib/libndctl.c | 3 --- >> > 1 file changed, 3 deletions(-) >> >> Ah apologies - this snuck in when I reflowed Dan's patches on top of the >> papr work for v70. No worries :-) >> >> I expect you'd like a point release with this fix asap? Yes, that will be great. Thanks >> >> Is there a way for me to incorporate some papr unit tests into my >> release workflow so I can avoid breaking things like this again? >> >> I'll also try to do a better job of pushing things out to the pending >> branch more frequently so if you're monitoring that branch, hopefully >> things like this will get caught before a release happens :) Fully agree, if that happens we can incorporate it into our CI system to ensure that such regressions are caught early on before any release is tagged. > > Would be nice to have something like a papr_test next to nfit_test for > such regression testing. These kinds of mistakes are really only > avoidable with regression tests. Yes Agree, fortunatly Santosh has recently posted an RFC patchset implementing such tests at [1]. Once that gets merged, can used to perform regression testing. [1] "testing/nvdimm: Add test module for non-nfit platforms" https://lore.kernel.org/linux-nvdimm/20201006010013.848302-1-santosh@foss...