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

[David McCullough]

Aleksander Morgado wrote the following:
> 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...

Thats sounds like a good approach.

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

I think its probably best to either disable the --with-newest-qmi-commands
configure command or highlight in the doc/help for it that it is incomplete
and broken and only for experimental use ;-)

Leaving the code there as a reference for now is useful to some extent I
guess.

Taking advantage of the extended commands on a case by case basis seems to
be the right way to move this forward.

I haven't looked specifically,  do you know of anything that could benefit
from the newer commands immediately ?

Thanks,
Davidm

-- 
David McCullough,  david.mccullough at accelecon.com,   Ph: 0410 560 763