[PATCH v3] telit: unsupported CSIM lock should not skip loading unlock retries

[Aleksander Morgado]

On Thu, Apr 13, 2017 at 6:09 PM, Dan Williams <dcbw at redhat.com> wrote:
>> > This thread turns out to be relevant to the latest in my battle
>> > with Cinterion modules. Their EHS5 doesn't support AT^SPIC, but it
>> > turns out it does support the CSIM commands used by the telit
>> > plugin - https://developer.gemalto.com/tutorial/how-query-pin-count
>> > er-ehsx
>>
>>
>> As a follow-on musing, does MM have mechanisms (or examples) for
>> cascaded fallback procedures - i.e. "Try to do this [set of
>> operations] using Method A, and if an an 'un-supported' error comes
>> back, then try Method B".....?
>> Is it just (ha!) a case of expanding out the 'context step' code
>> flow?
>
> Right, if you have [set of operations A] and then [set of operations B]
> and need to jump to B if some part of A fails, that's usually done
> through the "context step" pattern that you've seen.  That pattern
> keeps all the flow decision logic in one place, rather than having it
> sprinkled around a bunch of different functions in the file.

If we find the CSIM-based method to be generic enough, we could add it
in the MMBroadbandModem object directly, and have subclasses that want
to use it just skip providing a custom method themselves (e.g. what
Telit would do) or use the "parent" implementation as fallback if the
plugin-specific one (e.g. AT^SPIC based in Cinterion) isn't supported.
In the latter case, though, the decision logic step would also be
required in e.g. the "context step" pattern, just calling the parent
implementation instead of a different custom one.

-- 
Aleksander
https://aleksander.es