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