Dell 5570 (Sierra) supported?

Bjørn Mork bjorn at mork.no
Wed Nov 26 01:26:26 PST 2014


Aleksander Morgado <aleksander at aleksander.es> writes:

> Bjørn, Dan, Roshan, any comment?

Looks fine to me FWIW. I do not know what to expect here.  I assume the
modem is allowed to use a lot of time, given that it is supposed to be
ready for action when the 'open-done' is sent.

BTW, I do have a generic complaint about fault handling in MM+libmbim:
It should be better at reverting to some known state whenever it
encounters something unexpected, instead of just repeating the failing
command over and over again.  For me this is very noticable of I
hibernate while MM is using the laptop internal modem.  My laptop always
powers off the mini-PCIe slots when the system powers off.  So any
internal modem will reboot during a hibernate+resume sequence, of course
leading to complete amnesia.  The USB core will however do its best
attempting to restore the device state on resume, papering over the
powerloss. So when MM wakes up, the modem appears to be there exactly as
it was before hibernation.  Until you talk to it....  Then you get
"NotOpened" failures.

AFAICS, this is expected and unavoidable [1].  MM should expect it, and
should just go back to the "unitialized modem" state whenever it
encounters a "NotOpened" response to *any* MBIM command.



[1] Not entirely true - the cdc_mbim driver could force a device reset
by disabling the "USB persist" feature for MBIM devices (removing the
.reset_resume callback).  And userspace (i.e. MM) could also do the same
per device, using the /sys/bus/usb/devices/*/power/persist sysfs
interface.

The problem is that this would be catastrophic for any MBIM + card
reader composite device with a mounted file system.  And such devices
are not uncommon.  Which is why I believe we can't do that "just" to
make the modem work over hibernate+resume.

See https://www.kernel.org/doc/Documentation/usb/persist.txt for more
info.



Bjørn


More information about the libmbim-devel mailing list