[review] New 'fibocom' plugin
Dan Williams
dcbw at redhat.com
Thu Jul 19 20:32:29 UTC 2018
On Thu, 2018-07-19 at 21:44 +0200, Aleksander Morgado wrote:
> On Thu, Jul 19, 2018 at 9:23 PM, Dan Williams <dcbw at redhat.com>
> wrote:
> > On Thu, 2018-07-19 at 21:10 +0200, Aleksander Morgado wrote:
> > > > On Chrome OS, we simply use ID_MM_PORT_IGNORE to ignore all AT
> > > > ports
> > > > on the L850-GL module (e.g.
> > > > https://chromium.googlesource.com/chromiumos/overlays/chromiumo
> > > > s-ov
> > > > erlay/+/master/net-misc/modemmanager-next/files/77-mm-fibocom-
> > > > port-
> > > > types.rules).
> > > >
> > > > The modem is functional with just MBIM and supported via the
> > > > generic
> > > > plugin, which is the approach we took on Chrome OS. IMHO, there
> > > > is
> > > > little added benefit with a new modem plugin. More importantly,
> > > > AT
> > > > probing takes quite some time, and I observed it often took 7
> > > > seconds.
> > > > We've been trying hard for some time to move everything to
> > > > purely
> > > > MBIM
> > > > or QMI :)
> > > >
> > >
> > > I'm going to extend this plugin in the following weeks with more
> > > features that will require the use of the AT port, e.g. GPS
> > > location
> > > and such. I agree that probing is a bit slow right now, but that
> > > is
> > > just because the DIAG port goes first through a series of AT
> > > probing
> > > steps which are not needed. For devices with fixed layouts like
> > > this
> > > one, adding udev tags to specify port types isn't bad IMO, and we
> > > should probably do that for the DIAG port (i.e. flag it as "not
> > > AT"
> > > for example).
> >
> > Agreed; ideally we can begin to restrict which ports we bother
> > probing
> > for DIAG, since with QMI and MBIM DIAG is much less useful these
> > days.
> >
>
> You may know this better than me; are all DIAG ports from all
> qualcomm
> modems ever of the same class/subclass/protocol? i.e. Cls=ff(vend.)
> Sub=ff Prot=ff
> In other words, should we bother probing QCDM for ports that are not
> ff/ff/ff?
Some will be different than ff/ff/ff, but I don't have examples
offhand. I will try to find some.
Dan
More information about the ModemManager-devel
mailing list