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.
> >
> > 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).
>
> 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_node *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);
}
cell = 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èl
