Re: [MM] API changes for 0.8

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
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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]