Re: ModemManager [PATCH 2/2] Take 3 of: Improvements to SIM PIN handling - Add EnabledFacilityLocks property

[Eric Shienbrood <ers google com>]

I guess I don't have a problem with merging them, although strictly speaking they refer to different things - locks vs. the PINs needed to unlock those locks.

Two other points to consider regarding lock/PIN handling in the new API:

• PIN, PUK, PIN2, and PUK2 are PINs for SIM locks. The rest are device locks, so having them belong to the *.Sim interface doesn't seem completely right. But 3gpp gloms them all together, so maybe we should just live with this.
• Shouldn't we add an argument to EnablePin and ChangePin that specifies the lock to which the operation should apply? This would mirror the CLCK and CPWD AT commands, which take the facility name as an argument. This would correct what seems to be an oversight in the current API.

Eric

On Wed, Nov 23, 2011 at 9:58 AM, Aleksander Morgado <aleksander lanedo com> wrote:

Hey Eric & Dan,

On Fri, 2011-11-11 at 15:10 -0500, Eric Shienbrood wrote:
> Subject: [PATCH] Added new property to track which facility locks are
> enabled.
>
> The property EnabledFacilityLocks on the .Modem.Gsm.Card interface
> is a bit mask that indicates which of the various personalization
> codes from 3GPP TS 22.022, plus the SIM PIN lock and SIM PIN2 lock,
> are enabled. The set of facility locks supported by the modem is
> determined at the time the modem is initialized, and the state of
> each supported lock (enabled or disabled) is determined. When the
> state of a lock changes, a property-change signal is sent out. Note
> that ModemManager only supports enabling and disabling SIM-PIN, via
> the EnablePin method on Modem.Gsm.Card.

One of the changes I did in the new API was to have a new enum being
reported in the "UnlockRequired" property instead of a string. I called
this "MMModemLock", see:
http://www.lanedo.com/~aleksander/modem-manager/api-20111123/mm-Flags-and-Enumerations.html#MMModemLock

I also included your new MMModemGsmFacility enum in the new API, as
well, named "MMModem3gppFacility":
http://www.lanedo.com/~aleksander/modem-manager/api-20111123/mm-Flags-and-Enumerations.html#MMModem3gppFacility

Any problem in merging these both types? It could be just making
MMModemLock be a flags value instead of an enum. As far as I can see
"MMModem3gppFacility" is a subset of "MMModemLock".

Cheers,

--
Aleksander