On Wed, 2015-01-28 at 11:43 -0500, Jeremy Moles wrote: > On 01/12/2015 12:50 PM, Dan Williams wrote: > > On Mon, 2015-01-12 at 12:44 -0500, Jeremy Moles wrote: > >> On 01/12/2015 12:42 PM, Dan Williams wrote: > >>> On Mon, 2015-01-12 at 12:39 -0500, Jeremy Moles wrote: > >>>> On 01/12/2015 12:34 PM, Dan Williams wrote: > >>>>> On Mon, 2015-01-12 at 11:04 -0500, Jeremy Moles wrote: > >>>>>> On 01/12/2015 10:46 AM, Dan Williams wrote: > >>>>>>> On Mon, 2015-01-12 at 10:12 -0500, Jeremy Moles wrote: > >>>>>>>> On 01/09/2015 02:24 PM, Dan Williams wrote: > >>>>>>>>> On Fri, 2015-01-09 at 12:14 -0500, Jeremy Moles wrote: > >>>>>>>>>> On 01/09/2015 12:01 PM, Jeremy Moles wrote: > >>>>>>>>>>> Hey everyone! I'm not entirely sure where else to ask this, and > >>>>>>>>>>> I'm > >>>>>>>>>>> somewhat desperate at this point having tried everything I'm > >>>>>>>>>>> capable of. > >>>>>>>>>>> > >>>>>>>>>>> We have a machine here with the card listed in the subject. It > >>>>>>>>>>> shows > >>>>>>>>>>> up in lsusb as: > >>>>>>>>>>> > >>>>>>>>>>> 1199:901f Sierra Wireless, Inc. > >>>>>>>>>>> > >>>>>>>>>>> It will work in Linux so far if--and ONLY IF--you boot into > >>>>>>>>>>> Windows > >>>>>>>>>>> first and then soft reboot into Linux. it appears that Windows > >>>>>>>>>>> does > >>>>>>>>>>> something to the modem that Linux (currently) does not, and I was > >>>>>>>>>>> wondering if anyone here had any advice on what I might try. > >>>>>>>>>>> > >>>>>>>>>>> What I've done so far: > >>>>>>>>>>> > >>>>>>>>>>> 1) There is a knob in the sysfs hierarchy for this device that > >>>>>>>>>>> lets me > >>>>>>>>>>> change the "config" (or something like that, I'm actually working > >>>>>>>>>>> on > >>>>>>>>>>> this machine remotely and the customer isn't available right now!) > >>>>>>>>>>> from 1 to 0, or 0 to 1. This ends up being necessary in fact, as > >>>>>>>>>>> after > >>>>>>>>>>> doing so the tty's appear and the device is ready to be > >>>>>>>>>>> perturbed. It > >>>>>>>>>>> responds to ATI commands and whatnot, but again, won't work > >>>>>>>>>>> properly > >>>>>>>>>>> unless booted in Windows first. I should mention I found this knob > >>>>>>>>>>> entirely by accident while hacking on qcserial and trying to > >>>>>>>>>>> accept > >>>>>>>>>>> different "port" numbers as they enumerated themselves... > >>>>>>>>>>> > >>>>>>>>>>> 2) I downloaded the CodeAurora GobiSerial driver (which, > >>>>>>>>>>> according to > >>>>>>>>>>> the changelog has a fix for "powering on" a device) and modified > >>>>>>>>>>> it to > >>>>>>>>>>> work with 3.17 and 3.18 kernels (essentially, this involved > >>>>>>>>>>> re-exporting usb-serial.c symbols like usb_serial_probe the code > >>>>>>>>>>> relied on). However, I haven't had a chance to try this yet, and > >>>>>>>>>>> I'm > >>>>>>>>>>> not entirely convinced (after looking through the code) it really > >>>>>>>>>>> does > >>>>>>>>>>> anything qcserial doesn't. > >>>>>>>>>>> > >>>>>>>>>>> Anyways, if anyone has any advice, please let us know! > >>>>>>>>>>> _______________________________________________ > >>>>>>>>>>> networkmanager-list mailing list > >>>>>>>>>>> networkmanager-list@gnome.org > >>>>>>>>>>> https://mail.gnome.org/mailman/listinfo/networkmanager-list > >>>>>>>>>>> > >>>>>>>>>> I should also mention I JUST found this thread: > >>>>>>>>>> > >>>>>>>>>> http://lists.freedesktop.org/archives/modemmanager-devel/2014-June/001301.html > >>>>>>>>>> > >>>>>>>>>> Which explains exactly what I was seeing when talking about my #1 > >>>>>>>>>> attempt (the config option in sysfs; again, it's miraculously I > >>>>>>>>>> found > >>>>>>>>>> that at all). > >>>>>>>>>> > >>>>>>>>>> I can't piece together everything the thread is talking about, but > >>>>>>>>>> it > >>>>>>>>>> may job someone's memory. I can also try e-mailing the author of > >>>>>>>>>> that > >>>>>>>>>> thread directly. > >>>>>>>>> When it's cold-booted under Linux, can you grab 'lsusb -v -d > >>>>>>>>> 1199:901F'? > >>>>>>>>> Also grab 'dmesg' output to see what driver messages there are. > >>>>>>>>> Next, > >>>>>>>>> if you have mbimcli installed, run 'sudo mmcli --firmware-list -m > >>>>>>>>> 0' and > >>>>>>>>> lets see what we have. > >>>>>>>>> > >>>>>>>>> Next warm-boot from Windows to Linux and run 'sudo mmcli > >>>>>>>>> --firmware-list > >>>>>>>>> -m 0' in case the previous one didn't work. > >>>>>>>>> > >>>>>>>>> Dan > >>>>>>>>> > >>>>>>>> Thank you for your reponse, Dan. I've attached the information you > >>>>>>>> asked > >>>>>>>> for to this e-mail, formatted in a way it can be easily > >>>>>>>> diff'd/vimdiff'd > >>>>>>>> at your leisure. > >>>>>>>> > >>>>>>>> You'll notice how the 'power-state' differs depending on the boot > >>>>>>>> type. > >>>>>>>> Also, the --firmware-list command failed to run, saying: > >>>>>>>> > >>>>>>>> error: modem has no firmware capabilities > >>>>>>> Yeah, I see now that the modem is using QMI instead of MBIM. So > >>>>>>> instead, try these twice, once under Linux and once after rebooting > >>>>>>> from > >>>>>>> Windows: > >>>>>> For the time being, I can only provide the information with the machine > >>>>>> being directly booted into Linux. When I have additional access later > >>>>>> today, I will provide the results of these commands after having booted > >>>>>> into Windows first. For now, however, read on... > >>>>>> > >>>>>> # qmicli -d /dev/cdc-wdm0 --dms-list-stored-images > >>>>>> error: couldn't list stored images: QMI protocol error (71): > >>>>>> 'InvalidQmiCommand' > >>>>>> > >>>>>> # qmicli -d /dev/cdc-wdm0 --dms-get-operating-mode > >>>>>> [/dev/cdc-wdm0] Operating mode retrieved: > >>>>>> Mode: 'low-power' > >>>>>> HW restricted: 'no' > >>>>>> > >>>>>> # qmicli -d /dev/cdc-wdm0 --dms-lget-revision > >>>>>> [/dev/cdc-wdm0] Device revision retrieved: > >>>>>> Revision: 'SWI9X15C_05.05.16.03 r22385 carmd-fwbuild1 > >>>>>> 2014/06/04 15:01:26' > >>>>>> > >>>>>>> qmicli -d /dev/cdc-wdm0 --dms-list-stored-images > >>>>>>> qmicli -d /dev/cdc-wdm0 --dms-get-operating-mode > >>>>>>> qmicli -d /dev/cdc-wdm0 --dms-get-revision > >>>>>>> > >>>>>>> THe other possibility is that the machine's rfkill handling isn't > >>>>>>> known > >>>>>>> to Linux, but since Windows knows, when you warm-boot to Linux the > >>>>>>> WWAN > >>>>>>> rfkill is disabled. What model laptop is this? (if it's a laptop) > >>>>>> This is a Lenovo W540 with the Gobi 5000 Lenovo-certified card > >>>>>> installed. > >>>>> Under Linux, can you use 'sudo minicom -D /dev/ttyUSBx' where x is the > >>>>> number of each of the USB serial ports, and run "at!pcinfo" on each one > >>>>> in turn? > >>>> Only ttyUSB2 responds to input, and "at!pcinfo" simply returned "ERROR". > >>>> > >>>> However, "ati" returned: > >>>> > >>>> Manufacturer: Sierra Wireless, Incorporated > >>>> Model: EM7355 > >>>> Revision: SWI9X15C_05.05.16.03 r22385 carmd-fwbuild1 2014/06/04 15:01:26 > >>>> MEID: A0000050A9C727 > >>>> ESN: 12802084172, 801FCD4C > >>>> IMEI: 356450050130001 > >>>> IMEI SV: 13 > >>>> FSN: FD334502680111 > >>>> +GCAP: +CIS707-A, CIS-856, CIS-856-A, +CGSM, +CLTE2, +MS, +ES, +DS, > >>>> +FCLASS > >>> My fault, "at!pcinfo?" is the actual command, and it'll look something > >>> like this (from my 7750): > >>> > >>> at!pcinfo? > >>> State: 1 (ONLINE) > >>> LPM force flags - W_DISABLE:0, User:0, Temp:0, Volt:0 > >>> W_DISABLE: 0 > >>> Poweroff mode: 1 > >>> LPM Persistent: 0 > >> State: LowPowerMode > >> LPM force flags - W_DISABLE:0, User:0, Temp:0, Volt:0, BIOS:1, GOBIIM:0 > >> W_DISABLE: 0 > >> Poweroff mode: 0 > >> LPM Persistent: 0 > > This says that it's BIOS that is forcing the device to be in low power > > mode. That means that the kernel rfkill drivers don't know how to > > handle WWAN rfkill on this laptop, and until that gets fixed you won't > > be able to use the card from coldboot under Linux :( > > > > The best thing you can do for now is maybe file a bug on > > bugzilla.kernel.org. The process will likely be similar to > > https://bugzilla.kernel.org/show_bug.cgi?id=47751 (though for > > thinkpad/lenovo instead of Sony) where you'll be asked to grab some BIOS > > information so kernel developers can debug it. > > > > I hope that helps... > > > > Dan > > > > I have filed the following bug: > > https://bugzilla.kernel.org/show_bug.cgi?id=92201
Jeremy, could you try the attached kernel driver patch? It attempts to do what the GobiNet drivers do by clearing the endpoint halts in both qmi_wwan and qcserial. Let's see if that makes any difference. Dan
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c index 22756db..eff2dfd 100644 --- a/drivers/net/usb/qmi_wwan.c +++ b/drivers/net/usb/qmi_wwan.c @@ -330,6 +330,12 @@ next_desc: if (status < 0 && info->control != info->data) { usb_set_intfdata(info->data, NULL); usb_driver_release_interface(driver, info->data); + } else { + /* Clearing an endpoint halt brings some Sierra devices (MC7355) + * out of low-power mode. + */ + printk(KERN_INFO "%s: clearing halt\n", __func__); + usb_clear_halt(dev->udev, dev->out); } /* Never use the same address on both ends of the link, even diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c index b2aa003..127f192 100644 --- a/drivers/usb/serial/qcserial.c +++ b/drivers/usb/serial/qcserial.c @@ -330,6 +331,23 @@ static void qc_release(struct usb_serial *serial) kfree(priv); } +int qc_port_probe(struct usb_serial_port *port) +{ + int retval; + + retval = usb_wwan_port_probe(port); + if (retval == 0) { + printk(KERN_INFO "%s: clearing halt\n", __func__); + /* Clearing an endpoint halt brings some Sierra devices (MC7355) + * out of low-power mode. + */ + usb_clear_halt(port->serial->dev, + usb_sndbulkpipe(port->serial->dev, + port->bulk_out_endpointAddress)); + } + return retval; +} + static struct usb_serial_driver qcdevice = { .driver = { .owner = THIS_MODULE, @@ -346,7 +364,7 @@ static struct usb_serial_driver qcdevice = { .chars_in_buffer = usb_wwan_chars_in_buffer, .attach = qc_attach, .release = qc_release, - .port_probe = usb_wwan_port_probe, + .port_probe = qc_port_probe, .port_remove = usb_wwan_port_remove, #ifdef CONFIG_PM .suspend = usb_wwan_suspend,
_______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list