Anyone testing an MC7430 or other MDM9x30 based modem

[Bjørn Mork]

Bjørn Mork <bjorn at mork.no> writes:

> (..or whatever the MDM9x30 was renamed to - they had some new fancy
> name, but marketing lingo doesn't stick very well to my brain)
>
> But that was not the question. The reason I ask is that I stumbled
> across this in the Sierra Wireless GobiNet driver:
>
>
>    // Send SetControlLineState request (USB_CDC)
>    //   Required for Autoconnect and 9x30 to wake up
>    result = usb_control_msg( pDev->mpNetDev->udev,
>                              usb_sndctrlpipe( pDev->mpNetDev->udev, 0 ),
>                              SET_CONTROL_LINE_STATE_REQUEST,
>                              SET_CONTROL_LINE_STATE_REQUEST_TYPE,
>                              CONTROL_DTR,
>                              /* USB interface number to receive control message */
>                              pDev->mpIntf->cur_altsetting->desc.bInterfaceNumber,
>                              NULL,
>                              0,
>                              100 );
>
>
> If there is something to that comment, then I guess we need driver
> changes to support these devices.  Which is why I'm eager to have as
> early testing as possible.  Don't know if anything like this will be
> acceptable for stable. Might be if we make it MDM9x30 specific, but then
> we'll have to keep track of chipsets as well.  Don't know if I want to
> do that.  But the low timeout might be because this is actually failing
> on (some?) older chipsets, and I am not willing to accept that.  Even if
> it is "only" 100ms.
>
> FYI: the MC74xx/EM74xx device IDs were added just a few days ago, so if
> you're going to test this, then you will have to add them yourself or
> use a really new kernel.  The "new_id method" should work fine if you
> don't want to rebuild the driver.
>
> Mostly mentioning this now because I'll need it when I Google this issue
> in a few months time.

Thanks to nice helpers both here and at Sierra Wireless, I can now
confirm that this message is necessary for the MC7455. And presumably
any other MDM9x30.  The qmi device is simply dead without that message.

Not only is it required, but the initial testing seems to indicate that
it is required on *every* device wakeup.  So if you run with autosuspend
enabled, which I hope you all do because it's really cool, then you need
to set "DTR" with that control message every time you want to talk to
the modem.

Luckily, waking up is abstracted nicely away in qmi_wwan_manage_power,
so adding this is a piece-of-cake. The only thing that worries me is
whether we can do this unconditionally, or if we have to make it
per-device. I'll test with all the QMI devices I have and see what
happens.  I really like the fact that there is so little device specific
in the current driver.  It makes it so much easier to add new devices,
both dynamically and by patching.  No need to figure out chipset or
firmware version first.

Well, if it works then it works.  I'll just have to test for a while.


Then someone has to figure out what all these are good for :)

[23 Nov 2015, 13:03:09] [Debug] [/dev/cdc-wdm1] QMI Device supports 30 services:
[23 Nov 2015, 13:03:09] [Debug] [/dev/cdc-wdm1]    ctl (1.5)
[23 Nov 2015, 13:03:09] [Debug] [/dev/cdc-wdm1]    wds (1.67)
[23 Nov 2015, 13:03:09] [Debug] [/dev/cdc-wdm1]    dms (1.14)
[23 Nov 2015, 13:03:09] [Debug] [/dev/cdc-wdm1]    nas (1.25)
[23 Nov 2015, 13:03:09] [Debug] [/dev/cdc-wdm1]    qos (1.6)
[23 Nov 2015, 13:03:09] [Debug] [/dev/cdc-wdm1]    wms (1.10)
[23 Nov 2015, 13:03:09] [Debug] [/dev/cdc-wdm1]    auth (1.3)
[23 Nov 2015, 13:03:09] [Debug] [/dev/cdc-wdm1]    at (1.2)
[23 Nov 2015, 13:03:09] [Debug] [/dev/cdc-wdm1]    voice (2.1)
[23 Nov 2015, 13:03:09] [Debug] [/dev/cdc-wdm1]    cat2 (2.24)
[23 Nov 2015, 13:03:09] [Debug] [/dev/cdc-wdm1]    uim (1.45)
[23 Nov 2015, 13:03:09] [Debug] [/dev/cdc-wdm1]    pbm (1.4)
[23 Nov 2015, 13:03:09] [Debug] [/dev/cdc-wdm1]    test (1.0)
[23 Nov 2015, 13:03:09] [Debug] [/dev/cdc-wdm1]    loc (2.0)
[23 Nov 2015, 13:03:09] [Debug] [/dev/cdc-wdm1]    sar (1.0)
[23 Nov 2015, 13:03:09] [Debug] [/dev/cdc-wdm1]    ts (1.0)
[23 Nov 2015, 13:03:09] [Debug] [/dev/cdc-wdm1]    tmd (1.0)
[23 Nov 2015, 13:03:09] [Debug] [/dev/cdc-wdm1]    wda (1.16)
[23 Nov 2015, 13:03:09] [Debug] [/dev/cdc-wdm1]    csvt (1.1)
[23 Nov 2015, 13:03:09] [Debug] [/dev/cdc-wdm1]    coex (1.0)
[23 Nov 2015, 13:03:09] [Debug] [/dev/cdc-wdm1]    pdc (1.0)
[23 Nov 2015, 13:03:09] [Debug] [/dev/cdc-wdm1]    rfrpe (1.0)
[23 Nov 2015, 13:03:09] [Debug] [/dev/cdc-wdm1]    dsd (1.0)
[23 Nov 2015, 13:03:09] [Debug] [/dev/cdc-wdm1]    ssctl (1.0)
[23 Nov 2015, 13:03:09] [Debug] [/dev/cdc-wdm1]    unknown [0x2e] (1.0)
[23 Nov 2015, 13:03:09] [Debug] [/dev/cdc-wdm1]    unknown [0x30] (1.0)
[23 Nov 2015, 13:03:09] [Debug] [/dev/cdc-wdm1]    unknown [0x31] (1.0)
[23 Nov 2015, 13:03:10] [Debug] [/dev/cdc-wdm1]    unknown [0x36] (1.0)
[23 Nov 2015, 13:03:10] [Debug] [/dev/cdc-wdm1]    rms (1.0)
[23 Nov 2015, 13:03:10] [Debug] [/dev/cdc-wdm1]    unknown [0xf5] (1.0)
[23 Nov 2015, 13:03:10] [Debug] QMI Device at '/dev/cdc-wdm1' ready



Bjørn