[PATCH] Telit plugin: add load_unlock_retries interface
Carlo Lobrano
c.lobrano at gmail.com
Tue Dec 15 23:42:55 PST 2015
Hi, thanks for the feedback, I'll apply the changes suggested.
> And I just realized after submitting that all errors are ignored
> during all the steps... I think the logic I suggested still applies,
> though, to keep clear who owns the 'retries' object.
>
> But now, shouldn't we fail with an error if e.g. none of the retries
> checks succeeds?
My idea here is to avoid skipping one or more checks of the retries only
because the previous one failed, this is why I used only logging messages
to signal the failures (and this is why I used mm_err, in place of
mm_warn), but yes, if none of the checks succeeds, return with a failure
would be the right thing to do.
I would put a flag in the Context struct to take trace that at least one
check succeeded and at the last step (PUK2) I would check this flag and
decide whether return with failure or not. What do you think about that?
Carlo
On Tue, 15 Dec 2015 at 17:41 Aleksander Morgado <aleksander at aleksander.es>
wrote:
> On Tue, Dec 15, 2015 at 5:38 PM, Aleksander Morgado
> <aleksander at aleksander.es> wrote:
> >
> > Looks like the 'retries' object is not being freed properly in the
> > case of errors. What you need to do is to make sure that the ownership
> > of the retries object is always transferred properly between the
> > different logic parts.
>
> And I just realized after submitting that all errors are ignored
> during all the steps... I think the logic I suggested still applies,
> though, to keep clear who owns the 'retries' object.
>
> But now, shouldn't we fail with an error if e.g. none of the retries
> checks succeeds?
>
> --
> Aleksander
> https://aleksander.es
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/modemmanager-devel/attachments/20151216/0dcddb7d/attachment.html>
More information about the ModemManager-devel
mailing list