SIM7100E

[Dan Williams]

On Wed, 2016-04-06 at 10:43 +0200, Aleksander Morgado wrote:
> On Wed, Apr 6, 2016 at 9:01 AM, Yegor Yefremov
> <yegorslists at googlemail.com> wrote:
> > 
> > > 
> > > > 
> > > > I have a problem with SIM7100E. Though kernel creates wwan0
> > > > device,
> > > > it
> > > > is not visible in ModemManager.
> > > Try the following patch if you can; also ensure you are building
> > > ModemManager with QMI support (which is the default).  Basically,
> > > we've
> > > never seen a QMI SimTech device before, and the SimTech plugin is
> > > only
> > > built to work with PPP-style devices.  So it may work but just
> > > not use
> > > the wwan0 port.  This patch will move your device to the generic
> > > QMI
> > > plugin:
> > > 
> > > diff --git a/plugins/simtech/mm-plugin-simtech.c
> > > b/plugins/simtech/mm-plugin-simtech.c
> > > index a38942d..941e2db 100644
> > > --- a/plugins/simtech/mm-plugin-simtech.c
> > > +++ b/plugins/simtech/mm-plugin-simtech.c
> > > @@ -113,6 +113,7 @@ mm_plugin_create (void)
> > >      static const gchar *subsystems[] = { "tty", NULL };
> > >      static const guint16 vendor_ids[] = { 0x1e0e, /* A-Link (for
> > > now) */
> > >                                            0 };
> > > +    static const gchar *forbidden_drivers[] = { "qmi_wwan",
> > > "cdc_mbim", NULL };
> > > 
> > >      return MM_PLUGIN (
> > >          g_object_new (MM_TYPE_PLUGIN_SIMTECH,
> > > @@ -121,6 +122,7 @@ mm_plugin_create (void)
> > >                        MM_PLUGIN_ALLOWED_VENDOR_IDS, vendor_ids,
> > >                        MM_PLUGIN_ALLOWED_AT,         TRUE,
> > >                        MM_PLUGIN_ALLOWED_QCDM,       TRUE,
> > > +                      MM_PLUGIN_FORBIDDEN_DRIVERS,  forbidden_dr
> > > ivers,
> > >                        NULL));
> > >  }
> > Thanks for the fix. Everything is working as expected. Tested with
> > SIM5360E and SIM7100E.
> > 
> > Will this change be included into upcoming 1.6.0 release?
> I was targeting to have the vendor-specific plugins provide QMI
> support themselves, instead of always falling back to the generic
> plugin looking for QMI support. The main reasoning is that the
> probing
> will be quicker if there's a VID-based filter that grabs the plugin
> right away, instead of falling back to generic, which among other
> things may try the vendor/product string probing, which is slower.
> Not
> sure if this idea is good or bad, but I think it makes sense.

Yeah I forgot about that and that approach makes sense.  At least the
patch confirms the issue :)

> What do you guys think? I believe the Telit plugin has the same
> 'issue', it doesn't explicitly support QMI and falls back to the
> generic plugin for the LN920.

Plugin-specific handling for QMI/MBIM is fine with me.  I can't get to
that patch before next week though.

Dan