Re: [MM] API changes for 0.8

[Aleksander Morgado <aleksander lanedo com>]

On 31/05/13 00:18, Dan Williams wrote:
> > >  * Renamed 'Bands' property to 'CurrentBands'.
> > > > >  * Renamed 'SetBands()' method to 'SetCurrentBands()'.
> > > > >
> > > > >  * Updated the 'SupportedModes' property to give a list of
> > > > > allowed+preferred combinations, instead of just a mask with all allowed
> > > > > ones. Signature changed from "u" to "a(uu)", where each item in the
> > > > > array is a pair of MMModemMode values (first one mask of allowed modes,
> > > > > second one a preferred mode). Modems supporting the change of
> > > > > allowed+preferred modes will expose the combinations they actually
> > > > > support. E.g.:
> > > > >
> > > > >     $> sudo mmcli -m 0
> > > > >       -------------------------
> > > > >       Modes    |      supported: 'allowed: 2g; preferred: none
> > > > >                |                  allowed: 3g; preferred: none
> > > > >                |                  allowed: 2g, 3g; preferred: none
> > > > >                |                  allowed: 2g, 3g; preferred: 2g
> > > > >                |                  allowed: 2g, 3g; preferred: 3g
> > > > >
> > > > >  * Merged the 'AllowedModes' and 'PreferredMode' into a single
> > > > > 'CurrentModes' property, with signature "(uu)". The pair of integers has
> > > > > the same logic as in 'SupportedModes', first one is mask of allowed
> > > > > modes and second one is a preferred mode.
> > > > >
> > > > >  * Renamed 'SetAllowedModes()' method to 'SetCurrentModes()', and
> > > > > updated the argument list to have only one item with signature "(uu)"
> > > > > (allowed mask + preferred). The allowed+preferred combination given must
> > > > > be one of those listed in 'SupportedModes', otherwise the operation will
> > > > > fail.
> This probably was the case before, but I noticed that CurrentModes isn't
> read from the modem until we enable the modem.  Correspondingly, we
> should probably reject any SetCurrentModes() calls unless the modem is
> enabled?  If we want to keep this behavior, then we should probably
> update the introspection data to note which properties can't be set
> until the modem is enabled.
>
> Otherwise, if we allow modes and other stuff to be changed before the
> modem is enabled, we should ensure that stuff is read before Enable()
> gets called.
>
> I could see an argument for changing bands, capabilities, modes, etc
> before the modem is enabled, but I'm pretty sure we should reject
> changing these properties while the SIM is locked, since half the time
> the AT commands for changing this stuff would be rejected by the device
> anyway.  Since the device has to be unlocked in order to be enabled,
> perhaps we should just enforce that restriction.
>
> On the other hand, it seems a bit odd to require the  modem to be
> powered up and potentially registered to the network to change
> properties that would make the modem re-register and reboot, too.  Not
> sure it's that big of a deal though?

We can load current modes and bands in the locked->disabled transition,
i.e. just after unlocking, and we therefore can allow SetCurrentBands()
and SetCurrentModes() while in Disabled state (not while in Locked
state). Also, changing current capabilities should be allowed even if
the modem is in FAILED state (e.g. due to missing SIM), as a multimode
device could be switched from 3GPP to 3GPP2.

Already did those changes in the branch, let me know what you think.

-- 
Aleksander