State of ModemManager built with --with-newest-qmi-commands

[Aleksander Morgado]

On Thu, Sep 11, 2014 at 4:36 AM, David McCullough
<david.mccullough at accelecon.com> wrote:
>
> Just after some feedback on the state (or expected state) of ModemManager
> when built with --with-newest-qmi-commands.
>
> I have been running it this way for some time thinking it would be good
> form and I think (from memory) it allows for retrieving extra signal
> information.
>
> I just returned to using a Sierra Wireless MC7354,  which works fine without
> enabling the newest qmi commands,  but completely fails with it.  The
> patches I have just posted are enough to get a connection but there is
> still a lot of things not working.
>
> For example,  the new RF band information code expects to get a list,
> but for this modem a single TLV value is returned,  not a list.
>
> Other values that are not getting filled in correctly include:
> access_tech, operator is, operator name.
>
> So based on my experience with the 7354, my guess is this code is largely
> unusued and untested at this point and probably not suitable for real use
> just yet ?
>
> Any thoughts on it i ngeneral appreciated,

Yes, totally untested since a long time. We probably should remove it
instead of having it around, until we start to add the newer QMI
messages on top of the old ones, but ONLY if the old ones aren't
enough. Some LTE-related stuff may be accessible only through the new
commands, for example...

So I would say, we need to identify which items would be needed with
the newer QMI commands and then integrate them in the standard
codebase, without needing to enable any configure option. What do you
think?

-- 
Aleksander
https://aleksander.es