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?
>
> 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?

Trying to brush up stuff for an initial submission I found more
interesting stuff to note, of course :)

The GobiNet driver will not toggle "needs_remote_wakeup" all the time
like we do (as part of the usbnet inheritance), based on the combined
"open" status of the netdev and the cdc-wdm device. Instead GobiNet sets
needs_remote_wakeup once in GobiUSBNetProbe() and clears it in
GobiNetDriverUnbind().

Similarily, GobiNet will send a USB_CDC_REQ_SET_CONTROL_LINE_STATE "set
DTR" request in RegisterQMIDevice(), called once from GobiUSBNetProbe(),
and a "clear DTR" request in DeregisterQMIDevice(), called once from
GobiNetDriverUnbind().

My first experiments indicated that a "set DTR" might be required every
time we set "needs_remote_wakeup", so I simply added the control request
logic to qmi_wwan_manage_power() so that it would do "set DTR" as
well. Being a fan of symmetry, it seemed natural to do a "clear DTR"
every time we would clear "needs_remote_wakeup" too.

But it now turns out the this has side effects on older devices.
Testing on an E392 (MDM9200) with really old (pre-WDA) firmware, shows
that clearing and setting DTR affects the QMI client allocations similar
to a "sync" request. This is a problem if we do a sequence of qmicli
requests, each one opening and closing the cdc-wdm device.  If the
driver doesn't see anything else needing the modem (netdev is down and
no other process has opened the cdc-wdm device), then it will allow it
to sleep between these calls.

The MDM9x30 change seems to be that the DTR clearing is implicit
whenever we clear "needs_remote_wakeup".  The effect of a clear/set DTR
sequence is not new.

We might have painted ourselves into a corner here. OK, *I* have painted
myself into the corner :) . Delegating the QMI client allocation to
userspace means that the driver does not know when its OK for the
firmware to release all resources.  Both netdev and cdc-wdm being closed
is not enough.  There can still be a userspace process holding a client
ID, assuming it can be used to talk to the firmware again.  That means
that we cannot ever clear "needs_remote_wakeup" on the MDM9x30.

What do we do about that?  Oh, I wish I had required the cdc-wdm device
being held open whenever you have a valid client ID.  Can we change that
now?  I guess not.  Any other way out of this?


Bjørn