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
