Anyone testing an MC7430 or other MDM9x30 based modem

[Bjørn Mork]

Aleksander Morgado <aleksander at aleksander.es> writes:
> On Mon, Nov 23, 2015 at 5:51 PM, Bjørn Mork <bjorn at mork.no> wrote:
>
>> 1) firmware needs USB_CDC_REQ_SET_CONTROL_LINE_STATE requests to wake up
>> from sleep.  Wkaing up takes a measurable amount of time.
>>
>> I have a qmi_wwan driver fix for this.  But it might need further
>> userspace adjustments to account for the wakeup delay.  Yes, we could
>> add a delay to the driver, but that will slow down every device wakeup
>> for no good reason.
>>
>> Still have to do some testing with an active connection, to see how the
>> effect on that will be.
>>
>
> Is the state of the modem kept after resuming from sleep; or is it to
> be treated as a full reboot?
>
> Any idea what the GobiAPI/GobiNet setup does with this delay?

I haven't studied it yet.  It might just keep the device awake all the
time?

> Would it be worth having in the kernel a list of devices which require
> the delay? :(
>
> Does it just ignore requests fully until ready? Or does it instead
> reply to the first one we sent after a long time?

The device ignores them. Looks like the firmware really is sleeping,
which makes sense.

>> If we can't find a way to work around this, then I guess we can't avoid
>> supporting 'raw IP' any longer.  But it will be a mess...  Guess I made
>> the wrong choice a few years ago. Well, I'm sure it won't be the last
>> time.
>>
>
> Oh, how sad is this... :/
>
> Does the CTL command help changing the data format?

Nope.

 bjorn at nemi:~$ qmicli -d /dev/cdc-wdm2  --device-open-net='net-802-3|net-no-qos-header' --wda-get-data-format
 error: couldn't open the QmiDevice: QMI protocol error (70): 'InvalidOperation'

I also tried all possible combinations of the Set Data Format request I
could think of, including experimenting with the TLVs we don't know the
meaning of (0x17, 0x18, 0x1a and 0x1b).  The QoS header setting can be
changed, and some of the aggregation settings.  But the Link Layer
Protocol is fixed on 'raw-ip' no matter what I do.

> Have you tried to Set Data Format as soon as the device is exposed?

Hmm, not really.  Will try that next.  But note that I was able to
change the QoS header setting.

I got around to testing with raw IP support in the driver, just to
verify that there aren't any other issues, and that worked fine.
Including DHCP.  So it is always an option.

So start thinking about how you wish to control that feature.  I'm
currently using my old "ethtool driver private flags" implementation,
which has this UI:

 nemi:/home/bjorn# ethtool --show-priv-flags wwan1
 Private flags for wwan1:
 raw_ip_mode: off
 nemi:/home/bjorn# ethtool --set-priv-flags wwan1 raw_ip_mode on

We could make it an automatic per-device config in the driver too. But I
don't know if that helps?  Maybe it does, if we do it only for devices
which will not respond to the "Set Data Format"?  But I guess userspace
still has to know about this? If so, then we might just as well put
userspace in control by some API.

I have to pause the testing for a while now.  Not enough time for these
things...


Bjørn