| Message ID | 1467577490-27810-1-git-send-email-bjorn@mork.no |
|---|---|
| State | Accepted, archived |
| Delegated to: | David Miller |
| Headers | show |
On Sun, 2016-07-03 at 22:24 +0200, Bjørn Mork wrote: > Several Lenovo users have reported problems with their Sierra > Wireless EM7455 modem. The driver has loaded successfully and > the MBIM management channel has appeared to work, including > establishing a connection to the mobile network. But no frames > have been received over the data interface. If this is needed in open() it must also be needed in reset_resume() Regards Oliver
Oliver Neukum <oneukum@suse.com> writes: > On Sun, 2016-07-03 at 22:24 +0200, Bjørn Mork wrote: >> Several Lenovo users have reported problems with their Sierra >> Wireless EM7455 modem. The driver has loaded successfully and >> the MBIM management channel has appeared to work, including >> establishing a connection to the mobile network. But no frames >> have been received over the data interface. > > If this is needed in open() it must also be needed in reset_resume() reset_resume needs fixing in general. This is completely unrelated to this bug. In fact, as we don't do any NCM control messages there in the current resume, I'm not sure this firmware bug is triggered by it. But it's untestable, because: reset_resume cannot work for MBIM. At least not with the driver/userspace model we have chosen. The driver does not have enough information about the device state to recreate it. It could maybe work for NCM, but I don't think it currently does. The NCM protocol requires some minimum driver and device negotiation, and the current NCM .reset_resume points to usbnet_resume which completely ignores that. Proposals for fixing reset_resume would of course be good, and I'll think about how to deal with it, but I don't think it should block fixing the current issue. They are not related. Bjørn
On Mon, 2016-07-04 at 13:40 +0200, Bjørn Mork wrote: > Oliver Neukum <oneukum@suse.com> writes: > > On Sun, 2016-07-03 at 22:24 +0200, Bjørn Mork wrote: > >> Several Lenovo users have reported problems with their Sierra > >> Wireless EM7455 modem. The driver has loaded successfully and > >> the MBIM management channel has appeared to work, including > >> establishing a connection to the mobile network. But no frames > >> have been received over the data interface. > > > > If this is needed in open() it must also be needed in reset_resume() > > reset_resume needs fixing in general. This is completely unrelated to > this bug. In fact, as we don't do any NCM control messages there in the I see. In general this would be a problem. > current resume, I'm not sure this firmware bug is triggered by it. But > it's untestable, because: OK, something needs to be done, but this patch is not the place to do it. Regards Oliver
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c index 53759c315b97..877c9516e781 100644 --- a/drivers/net/usb/cdc_ncm.c +++ b/drivers/net/usb/cdc_ncm.c @@ -854,6 +854,13 @@ int cdc_ncm_bind_common(struct usbnet *dev, struct usb_interface *intf, u8 data_ if (cdc_ncm_init(dev)) goto error2; + /* Some firmwares need a pause here or they will silently fail + * to set up the interface properly. This value was decided + * empirically on a Sierra Wireless MC7455 running 02.08.02.00 + * firmware. + */ + usleep_range(10000, 20000); + /* configure data interface */ temp = usb_set_interface(dev->udev, iface_no, data_altsetting); if (temp) {
Several Lenovo users have reported problems with their Sierra Wireless EM7455 modem. The driver has loaded successfully and the MBIM management channel has appeared to work, including establishing a connection to the mobile network. But no frames have been received over the data interface. The problem affects all EM7455 and MC7455, and is assumed to affect other modems based on the same Qualcomm chipset and baseband firmware. Testing narrowed the problem down to what seems to be a firmware timing bug during initialization. Adding a short sleep while probing is sufficient to make the problem disappear. Experiments have shown that 1-2 ms is too little to have any effect, while 10-20 ms is enough to reliably succeed. Reported-by: Stefan Armbruster <ml001@armbruster-it.de> Reported-by: Ralph Plawetzki <ralph@purejava.org> Reported-by: Andreas Fett <andreas.fett@secunet.com> Reported-by: Rasmus Lerdorf <rasmus@lerdorf.com> Reported-by: Samo Ratnik <samo.ratnik@gmail.com> Reported-and-tested-by: Aleksander Morgado <aleksander@aleksander.es> Signed-off-by: Bjørn Mork <bjorn@mork.no> --- I hope this unconditional short sleep during probing is acceptable, as I don't want to start a new non-maintainable quirk device list for this. The EM7455 is already used by a number of laptop vendors, each using their own device ID. More are likely to come. And that's only the modems we *know* are affected... drivers/net/usb/cdc_ncm.c | 7 +++++++ 1 file changed, 7 insertions(+)