Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) client-ip=23.128.96.36;
Date:   Wed, 11 Oct 2023 12:58:59 +0200
From:   Miquel Raynal <miquel.raynal@bootlin.com>
To:     Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Cc:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Michael Walle <michael@walle.cc>,
        =?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= <rafal@milecki.pl>,
        Rob Herring <robh+dt@kernel.org>,
        Frank Rowand <frowand.list@gmail.com>,
        devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
        Robert Marko <robert.marko@sartura.hr>,
        Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
        Luka Perkov <luka.perkov@sartura.hr>,
        Randy Dunlap <rdunlap@infradead.org>,
        Chen-Yu Tsai <wenst@chromium.org>,
        Daniel Golle <daniel@makrotopia.org>
Subject: Re: [PATCH v12 5/7] nvmem: core: Rework layouts to become regular
 devices
Message-ID: <20231011125859.1647c08c@xps-13>
In-Reply-To: <04112100-026c-b010-6e8c-730049d43e47@linaro.org>
References: <20231005155907.2701706-1-miquel.raynal@bootlin.com>
        <20231005155907.2701706-6-miquel.raynal@bootlin.com>
        <dc96ddb1-502c-e643-7749-d057d1fc6490@linaro.org>
        <20231011093843.49831a75@xps-13>
        <04112100-026c-b010-6e8c-730049d43e47@linaro.org>
Organization: Bootlin
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Hi Srinivas,

> > you don't have access to your modules. And anyway it's probably a bad
> > idea to allow endless probe deferrals on your main storage device.
> >=20
> > If the cells are not available at that time, it's not a huge deal? The
> > consumers will have to wait a bit more (or take any other action, this
> > is device dependent). =20
>=20
> In this case the nvmem consumers will get an -ENOENT error, which is very=
 confusing TBH.

Maybe we can solve that situation like that (based on my current
series):

--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -1448,7 +1448,10 @@ struct nvmem_cell *of_nvmem_cell_get(struct device_n=
ode *np, const char *id)
        of_node_put(cell_np);
        if (!cell_entry) {
                __nvmem_device_put(nvmem);
-               return ERR_PTR(-ENOENT);
+               if (nvmem->layout)
+                       return ERR_PTR(-EAGAIN);
+               else
+                       return ERR_PTR(-ENOENT);
        }
=20
        cell =3D nvmem_create_cell(cell_entry, id, cell_index);


So this way when a (DT) consumer requests a cell:
- the cell is ready and it gets it
- the cell is not ready and...
   - the cell comes from a layout -> we return EAGAIN, which
     means the cell is not yet ready and this must be retried later
     (the caller may return EPROBE_DEFER in this case).
   - the cell is simply missing/not existing/not available, this is a
     real error.

What do you think?

Thanks,
Miqu=C3=A8l