ANN: ModemManager 1.5.993 (1.6-rc4) released

Bjørn Mork bjorn at mork.no
Fri Jul 8 11:03:39 UTC 2016


Aleksander Morgado <aleksander at aleksander.es> writes:

> Hey hey,
>
> This 1.5.993 is the fourth release candidate version towards 1.6.0,
> tagged as 1.6-rc4.
>
> This release implements support for sending the QMI FCC authentication
> command via QMI-over-MBIM if power-up fails via plain MBIM. This new
> feature requires libmbim 1.14.0 and libqmi 1.16.0, which will be the new
> versions used as base for the 1.6.0 release.
>
> NOTE: Devices like the MC7455 or the EM7455 (when running in MBIM mode)
> will require this additional patch in the NCM driver from Bjørn, which I
> believe hasn't been released in any stable Linux version yet:
>    ** http://www.spinics.net/lists/linux-usb/msg143399.html

Correct.  It is on its way to a kernel near you.  Going into v4.7-rc7
real soon (on Sunday, most likely):
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/net/usb/cdc_ncm.c?id=c086e7096170390594c425114d98172bc9aceb8a

And it is also in davem's stable queue:
http://patchwork.ozlabs.org/bundle/davem/stable/?state=*

So it should eventually show up in stable kernels. This will take some
time, because netdev stable patches need to be in mainline for a while
first.  But in a week or two you'll all use v4.7, so who cares? ;)

> NOTE: I didn't merge all the patches from the qmi-over-mbim branch, as
> the remaining ones were forcing all MBIM devices to do the FCC auth
> command, even if power-up would succeed. If someone finds any problem
> without these patches added, lease report.


I'll report success instead :)

I tried this release together with the latest master-branches of libqmi
and libmbim, which I believe should be identical to libmbim 1.14.0 and
libqmi 1.16.0 at the moment, except for the development version numbers.

I tested booting from poweroff and resuming from hibernate [1] on an
Thinkpad X1 Carbon with the original Lenovo configured EM7455. This
worked so well for me that I had to look into the MM logs to make sure
that the modem still needed that FCC Auth thing.

With debugging off, it's actually hard to notice even from the logs
(which is good).  But the "Opening device with flags" message from
libqmi is revealing:

Jul  8 11:02:01 miraculix ModemManager[2191]: [/dev/cdc-wdm0] Opening device with flags 'proxy, mbim'...
Jul  8 11:02:01 miraculix ModemManager[2191]: [/dev/cdc-wdm0] creating MBIM device...
Jul  8 11:02:01 miraculix ModemManager[2191]: [/dev/cdc-wdm0] MBIM device created
Jul  8 11:02:01 miraculix ModemManager[2191]: [/dev/cdc-wdm0] opening MBIM device...
Jul  8 11:02:01 miraculix ModemManager[2191]: opening device...
Jul  8 11:02:01 miraculix ModemManager[2191]: [/dev/cdc-wdm0] Read max control message size from descriptors file: 4096
Jul  8 11:02:01 miraculix ModemManager[2191]: [/dev/cdc-wdm0] MBIM device open
Jul  8 11:02:01 miraculix ModemManager[2191]: [/dev/cdc-wdm0] Assuming service 'dms' is supported...


This is really great news for all those frustrated Lenovo EM7455 users.
There is no reason to ask which modem for your new Thinkpad: The EM7455
is superior, unless you need 2G.


Bjørn

[1] This needs a quirk to work around some driver/kernel things I don't
  understand.  Should be fixed properly at some time.  For now, I've
  used a static udev rule:
  
   ATTR{idVendor}=="1199", ATTR{idProduct}=="9079", ATTR{power/persist}="0"

  The problem is that modem is powered down (of course), but the kernel
  hides this fact and makes it appear as the same device after resume.
  That might be techically correct from one point of view, but the
  resulting "not opened" MBIM errors confuses the hell out of MM.

  Turning off "persist" prevents this kernel behaviour, and makes MM see
  the modem as a "new" device after resume.


More information about the ModemManager-devel mailing list