[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPcyv4jXS-doCdyTrcV3DL63N-q4m1H2=Msgm1z88HnF8bcEig@mail.gmail.com>
Date: Mon, 21 Jan 2019 16:29:08 -0800
From: Dan Williams <dan.j.williams@...el.com>
To: Wei Yang <richardw.yang@...ux.intel.com>
Cc: linux-nvdimm <linux-nvdimm@...ts.01.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] libnvdimm: Clarify nd_pfn_init() flow
On Mon, Jan 21, 2019 at 4:26 PM Wei Yang <richardw.yang@...ux.intel.com> wrote:
[..]
> >@@ -706,6 +711,22 @@ static int nd_pfn_init(struct nd_pfn *nd_pfn)
> > sig = DAX_SIG;
> > else
> > sig = PFN_SIG;
> >+
> >+ /*
> >+ * Check for an existing 'pfn' superblock before writing a new
> >+ * one. The intended flow is that on the first probe of an
> >+ * nd_{pfn,dax} device the superblock is calculated and written
> >+ * to the namespace. In this case nd_pfn_validate() returns
> >+ * -ENODEV because no valid superblock exists currently.
>
> As you replied in following mail:
>
> 3/ If present, nd_pfn_validate() returns 0 and nd_dax_probe()
> registers the dax0.1 device (this is a libnvdimm 'personality device).
>
> So at this point, nd_pfn_validate() return 0 or -ENODEV?
In this case 0, because the configuration was successfully validated.
-ENODEV, is only returned for the initial case where we want the
kernel to write the configuration.
All other error codes are an actual failure and the probe procedure stops.
Powered by blists - more mailing lists