>>>> It really is unfortunate that the MBIM_CID_PIN query only reports the >>>> information of the "currently applicable" PIN type, although the truth >>>> is that that's the only useful one. >>> >>> Yes, indeed. It would have been much better if MBIM_CID_PIN query >>> could take a PIN type as argument. I'd expect PIN1 (PUK1) is likely >>> the one being used and thus the most relevant / useful one in typical >>> scenarios. >>> >>> Here's the issue: If PIN1 is currently disabled, some modem reports >>> the info about another PIN, say PIN2, to a MBIM_CID_PIN query. When we >>> try to enable PIN1, we won't know the retries count until after >>> entering a PIN once. Suppose the retries count doesn't go to 0 after a >>> wrong attempt (i.e. not in sim-puk state), we still can't query MM for >>> the retries count of PIN1. >>> >> >> Aha, that was what I was missing, the PIN disabled->enabled transition >> is the problematic one, because with PIN disabled it would report you >> PIN2 attempts. But, if we do the disabled->enabled transition, >> couldn't we reload unlock attempts in that moment (after enabling >> SIM-PIN)? I'm assuming that the "current" PIN would change to PIN1 >> right away and we would get reported the number of attempts of PIN1; >> without even trying to send a PIN once. >> > > Don't we need to enter the correct PIN to re-enable PIN1? so the > disabled->enabled transition is essentially a MBIM_CID_PIN set > operation. Regardless of whether the operation succeeds or fails, the > response should report the latest remaining attempts for PIN1, which > we want to propagate that to UnlockRetries. That's why patch #4 always > calls mm_iface_modem_update_unlock_retries() if we can parse the > response, regardless of whether the operation succeeds or not. >
That makes total sense, indeed. Your logic makes the best compromise given the APIs we have in MBIM. -- Aleksander https://aleksander.es _______________________________________________ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel