On Fri, 3 Mar 2017 13:34:19 +0100 Boris Brezillon <boris.brezil...@free-electrons.com> wrote:
> On Fri, 3 Mar 2017 11:23:16 +0000
> Srinivas Kandagatla <srinivas.kandaga...@linaro.org> wrote:
>
>
> >
> > > + mutex_lock(&mtd_nvmem_list_lock);
> > > + list_for_each_entry(mtd_nvmem, &mtd_nvmem_list, list) {
> > > + if (mtd_nvmem->mtd == mtd) {
> > > + list_del(&mtd_nvmem->list);
> > > + found = true;
> > > + break;
> > > + }
> > > + }
> > > + mutex_unlock(&mtd_nvmem_list_lock);
> > > +
> > > + if (found) {
> > > + if (nvmem_unregister(mtd_nvmem->nvmem))
> > > + dev_err(&mtd->dev,
> > > + "Failed to unregister NVMEM device\n");
> >
> > I will be nice to feedback error to top layer, as it does not make sense
> > to remove providers if there are active consumers using it.
> >
> > del_mtd_device(), unregister_mtd_user() have return values, I see no
> > reason why notifiers should not return errors.
> > May be if we should fix the remove() call backs to handle and return
> > errors.
>
> It's more complicated than that. What should you do if one of the
> ->remove() notifier in the middle of the list is returning an error?
> Some of them have already taken the remove notification into account.
> Should we call ->add() back on those notifiers? Also, I'm not sure they
> are all safe against double ->remove() calls, so if we might be in
> trouble when the removal is retried.
Re-adding make no sense as that could also fails. Keep it simple,
remove the notifier from the list when remove() succeed, abort when one
fails. In such a scenario that mean there is a dependency, the sys
admin should then solve this dependency and re-trigger the MTD removal.
Alban
pgphvp81ItmbC.pgp
Description: OpenPGP digital signature
