Fwd: cinterion: modification to fetching unlock retries
Colin Helliwell
colin.helliwell at ln-systems.com
Sat Dec 30 14:23:47 UTC 2017
> On 30 December 2017 at 11:38 Colin Helliwell wrote:
>
>
> > From: Aleksander Morgado
> > Date: Fri, Dec 29, 2017 at 10:09 PM
> > Subject: Re: cinterion: modification to fetching unlock retries
> > To: Colin Helliwell
> >
> >
> > Hey,
> >
> > On Fri, Dec 29, 2017 at 2:27 PM, Colin Helliwell wrote:
> > > I fear though, that the fallback route is going to be beyond my
> > > understanding!
> > >
> > > I was though wondering what the plugin 'error' condition should be - perhaps
> > > it should ideally try *all* the plugin commands and only fallback if any of
> > > them have failed. i.e. not simply fallback *as soon as* one fails - perhaps
> > > some/all of the other SPIC commands would work, and the generic would only
> > > be needed to fill in the blanks? (though as I mentioned yesterday - let's
> > > hope a positive result of one method doesn't contradict a corresponding
> > > positive result of the other!)
> >
> > I believe that the rationale here is to say; if SPIC is supported in
> > any way, use SPIC; otherwise use the fallback generic method. Now,
> > "supported in any way" to me means that we can run "AT^SPIC=?" to
> > check the format of the command and that check doesn't return an
> > error. This test could be cached in the private info of the modem
> > object as a "FeatureSupported" enum (as done in other plugins), so
> > that it is only checked once.
>
> I can see that perhaps one way to do this would be to add the "AT^SPIC=?" as the first step of the plugin's unlock_retries_map[] - spic_ready() can then easily catch ctx->i being zero, not fully parse the response but just look for an error and set the 'FeatureSupported' accordingly. The non-zero cases would parse for the count value as now.
> And the zero case would also be the one which, if it errors, triggers the fall back to the generic method?
>
How does the attached look...?
It seems to work for me, but I'm really not sure about the integrity of the cleanup - I wouldn't bet against there being leaks....
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cint_fallback.patch
Type: application/octet-stream
Size: 4820 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/modemmanager-devel/attachments/20171230/42c0d3da/attachment.obj>
More information about the ModemManager-devel
mailing list