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

[Aleksander Morgado]

On Fri, Sep 12, 2014 at 3:15 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 ;-)
>

That's true. I'll actually remove the configure option but leave it
#ifdef-ed in the code. If anyone wants to enable that code, you'll
need to explicitly define some symbol in CFLAGS; like ./configure
"CFLAGS=-DNEWER_QMI_COMMANDS or something. That is less exposed than
the configure option and still useful if needed.

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

Yep.

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

I recall seeing some LTE related stuff that could only be done with
the new commands, but don't remember exactly what. That was a long
time ago :)

-- 
Aleksander
https://aleksander.es