Anyone testing an MC7430 or other MDM9x30 based modem

[Bjørn Mork]

Aleksander Morgado <aleksander at aleksander.es> writes:
> On Thu, Dec 3, 2015 at 2:39 PM, Bjørn Mork <bjorn at mork.no> wrote:
>>
>> 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?
>
> This issue would likely only affect qmicli without proxy usage. As
> soon as the qmi-proxy is used the cdc-wdm device should be kept open
> as long as there are clients registered (i.e. even with a sequence of
> qmicli calls re-using the same id). ModemManager (uses qmi-proxy as
> well), uqmi and ofono will all keep the port open as well if I'm not
> mistaken. So I'd say it may not be that big of an issue, if the
> needs_remote_wakeup stuff is mandatory in the driver; we can always
> just require the qmi-proxy when qmicli is being used. Not saying we
> should do it, just saying that we always have that option if there's
> no other way to do it :)

There are always ways :)

The questions are: How ugly code can be accepted?  Am I making bogus
assumptions?

I am currently playing with this in _bind(), and it seems to do the job:

	if (le16_to_cpu(dev->udev->descriptor.bcdUSB) >= 0x0201) {
		qmi_wwan_manage_power(dev, 1);
		qmi_wwan_change_dtr(dev, true);
	}


This abuses the fact(?) that MDM9x30 is the first QMI chipset with USB3
support.  It then forces remote_wakeup on by increasing the "open"
counter, and also sets DTR on. This should not change driver behaviour
for any older devices. This is important for devices without remote
wakeup support, because they cannot be auto-suspended unless we clear
"needs_remote_wakeup".

I am tempted to submit this as an initial attempt on MDM9x30 support.
It has the advantage that it doesn't touch any previously supported
device.  Unless I'm mistaken wrt the USB3 test...



Bjørn