Fwd: cinterion: modification to fetching unlock retries

[Colin Helliwell]

> From: Aleksander Morgado <aleksander at aleksander.es>
> 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?

What do you think?