Cinterion modems

[Giacinto Cifelli]

Hi Aleksander,

On Fri, Mar 20, 2020 at 4:01 PM Aleksander Morgado
<aleksander at aleksander.es> wrote:
>
> Hey Giacinto,
>
> > I would like to add some Cinterion/Gemalto/Thales modems in
> > ModemManager, and I have some questions:
>
> Nice!
>
> > - first of all, if code from the modem vendors are welcome
> > - is there a procedure to submit commits? I see that on the gitlab
> > page there are some pull requests. Is it enough to create an account
> > and do a pull request?
>
> Yes, that is enough. The request will be reviewed, and if more changes
> are needed, they'll be requested.

thank you, will do.

>
> > - is there a preferred or forbidden way to code for some behaviors?
> >    . To be more specific, if a modem supports both AT and QMI
> > interfaces, is there a community preference that would override the
> > vendor one? For the Cinterion modems, so far, the vendor supports AT
> > commands, even if the QMI interface is sometimes available.
> >    . Some modems support AT+MBIM, and should be used at the same time.
> > Is this acceptable for the ModemManager community?
> >
>
> So, in general if a feature is available in either QMI or MBIM, that
> is always preferred. If the feature isn't available via QMI/MBIM, then
> AT fallback can be used. And definitely, the modems can use both if
> available, following the previous rules. If there are features that
> are shared between e.g. QMI-capable and AT-only-capable devices, e.g.
> GPS management in the cinterion devices, then that would go to the
> "shared" interface of the plugin, and then used by the multiple
> different modem types. E.g. the MMSharedCinterion interface provides
> features implemented both by the AT-only MMBroadbandModemCinterion and
> by the AT+QMI MMBroadbandModemQmiCinterion.

we struggle to keep the AT interface as much compatible as possible
among models, and it is what we validate extensively.
QMI, being used internally, can lead to inexplicable conflicts (in
theory, I never observed that).
I believe that the old TC75i, already supported, will be pretty much
compatible already with more recent models.

>
> > One additional topic: building the source code, I spent some time
> > checking a build error, and found out that xsltproc was not installed
> > on my machine, but no direct error was produced.
> > For problems like this, a simple patch in the configure.ac like the following:
> > +AC_CHECK_PROG(XSLTPROC_CHECK,xsltproc,yes)
> > +AS_IF([test x"$XSLTPROC_CHECK" != x"yes"], [AC_MSG_ERROR([Please
> > install xsltproc before configuring.])])
> > My questions are: is there a fast way to submit a simple patch like
> > this or needs a pull request? Should such a patch also have a matching
> > bug?
>
> No need to create a bug report for that. You can either create a merge
> request in gitlab, or send the patch to the mailing list, whatever you
> prefer.

submitted as a patch. I hope it is ok.

> Cheers!

Thank you for your welcoming,

>
> --
> Aleksander
> https://aleksander.es

regards,
Giacinto