[review] https://github.com/cbchan/ModemManager/tree/sim-mbim-unlock-retries

[Aleksander Morgado]

>>> However, we may be able to improve the situation a bit when MM is
>>> running by making mm_iface_modem_update_lock_info preserve what we
>>> have learned from a prior MBIM_CID_PIN response.  That's what I'm
>>> trying to address with this patch set.
>>>
>>
>> Yes, I agree, keeping the information returned in a response is
>> useful, but why not fully overwrite the list of unlock attempts
>> instead of merging as you were trying?
>
> Let me make sure I understand your proposal. Are you suggesting the following?
>
> (1) When MMSimMbim receives a response to a MBIM_CID_PIN set
> operation, it always overwrite IfaceModem's MMUnlockRetries as
> MBIM_CID_PIN provides the most relevant info at that point, which I
> think makes sense (e.g. we really don't care about PIN2 in MM, at
> least for now. And we don't care about PIN1 when PUK1 is active)
>
> (2) When MMBroadbandModemMbim later reload unlock retries via a
> MBIM_CID_PIN query, we try to preserve PIN1 in IfaceModem's
> MMUnlockRetries if MBIM_CID_PIN query reports PIN2, for example.
>

I was actually suggesting we leave this as it is now (i.e. query pin
lock and retries, and just use that, without merging)...

>From a user point of view, we have the main features we need:
  * If locked, we know the lock enabled and the amount of unlock retries left.
  * We know if a lock unlock operation succeeds or fails, and if it
fails we know the amount of unlock retries left.
  * We know if a lock enable/disable operation succeeds or fails.

What we don't know is the amount of retries left if the lock
enable/disable operation fails. We could try to hack something in MM
to keep some of that logic, but then, if the device/system is rebooted
between e.g. failed lock enable attempts, we're back without knowing
anything until we let the user retry again. There's no perfect
solution either way, not sure.

-- 
Aleksander
https://aleksander.es