[PATCH 1/1] drivers: net: usb: qmi_wwan: add QMI_QUIRK_SET_DTR for Telit PID 0x1201

[PATCH 1/1] drivers: net: usb: qmi_wwan: add QMI_QUIRK_SET_DTR for Telit PID 0x1201

[Daniele Palmas]

Telit LE920A4 uses the same pid 0x1201 of LE920, but modem
implementation is different, since it requires DTR to be set for
answering to qmi messages.

This patch replaces QMI_FIXED_INTF with QMI_QUIRK_SET_DTR: tests on
LE920 have been performed in order to verify backward compatibility.

Signed-off-by: Daniele Palmas <dnlplm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---

Hi Bjørn,

as a side note in latest kernels I had troubles with qmi devices
(e.g. I/O error when using qmicli).

I found your suggestion in libqmi mailing list to revert commit

833415a3e781a26fe480a34d45086bdb4fe1e4c0
cdc-wdm: fix "out-of-sync" due to missing notifications

and this seems to work.

Regards,
Daniele

---
 drivers/net/usb/qmi_wwan.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 156f7f8..2474618 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -908,7 +908,7 @@ static const struct usb_device_id products[] = {
 	{QMI_FIXED_INTF(0x2357, 0x9000, 4)},	/* TP-LINK MA260 */
 	{QMI_QUIRK_SET_DTR(0x1bc7, 0x1040, 2)},	/* Telit LE922A */
 	{QMI_FIXED_INTF(0x1bc7, 0x1200, 5)},	/* Telit LE920 */
-	{QMI_FIXED_INTF(0x1bc7, 0x1201, 2)},	/* Telit LE920 */
+	{QMI_QUIRK_SET_DTR(0x1bc7, 0x1201, 2)},	/* Telit LE920, LE920A4 */
 	{QMI_FIXED_INTF(0x1c9e, 0x9b01, 3)},	/* XS Stick W100-2 from 4G Systems */
 	{QMI_FIXED_INTF(0x0b3c, 0xc000, 4)},	/* Olivetti Olicard 100 */
 	{QMI_FIXED_INTF(0x0b3c, 0xc001, 4)},	/* Olivetti Olicard 120 */
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/1] drivers: net: usb: qmi_wwan: add QMI_QUIRK_SET_DTR for Telit PID 0x1201

[David Miller]

From: Daniele Palmas <dnlplm@gmail.com>
Date: Mon, 10 Apr 2017 17:34:23 +0200

> Telit LE920A4 uses the same pid 0x1201 of LE920, but modem
> implementation is different, since it requires DTR to be set for
> answering to qmi messages.
> 
> This patch replaces QMI_FIXED_INTF with QMI_QUIRK_SET_DTR: tests on
> LE920 have been performed in order to verify backward compatibility.
> 
> Signed-off-by: Daniele Palmas <dnlplm@gmail.com>

Applied, thank you.

Re: [PATCH 1/1] drivers: net: usb: qmi_wwan: add QMI_QUIRK_SET_DTR for Telit PID 0x1201

[Bjørn Mork]

Daniele Palmas <dnlplm@gmail.com> writes:

> as a side note in latest kernels I had troubles with qmi devices
> (e.g. I/O error when using qmicli).
>
> I found your suggestion in libqmi mailing list to revert commit
>
> 833415a3e781a26fe480a34d45086bdb4fe1e4c0
> cdc-wdm: fix "out-of-sync" due to missing notifications

I guess a revert of that commit should be done then..

I have been stalling because I have been hoping to replace it with a
better fix instead of a plain revert. I believe there are several issues
playing badly together here.  That commit was _expected_ to cause
spurious EPIPE errors, which would be translated to EIO if they were
propagated.  But they should be filtered out rightaway, in theory. This
works for me.  I can see the EPIPEs with debugging, but I have never
seen any EIO from read.

And there is the problem: I am unable to reproduce this problem.  I have
previously tested this back and forth with several MDM9200 and MDM9235
generation modems in QMI mode, as well as in MBIM mode.  And also with a
number of other MBIM modems.  Aleksander reported that he could
reproduce the issue using an MDM9x15 generation modem in QMI mode, but
not with any MDM9x00 or MDM9x35 modem.  So I have now tried any way I
can imagine to reproduce the issue with a Sierra Wireless EM7305, which
is the only MDM9x15 modem I have. The firmware is SWI9X15C_05.05.58.00.

But unfortunately the testing is still without "success".  It plain
works for me, every time, using ModemManager, qmicli with or without
proxy, or uqmi.

Would you mind describing in detail how you trigger the EIOs?  What
software and command sequence are you using?  Does it reliably reproduce
the issue, or do you have to try several times?  What modem chipset and
firmware is used?




Bjørn

Re: [PATCH 1/1] drivers: net: usb: qmi_wwan: add QMI_QUIRK_SET_DTR for Telit PID 0x1201

[Aleksander Morgado]

On Wed, Apr 19, 2017 at 7:28 PM, Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org> wrote:
>> as a side note in latest kernels I had troubles with qmi devices
>> (e.g. I/O error when using qmicli).
>>
>> I found your suggestion in libqmi mailing list to revert commit
>>
>> 833415a3e781a26fe480a34d45086bdb4fe1e4c0
>> cdc-wdm: fix "out-of-sync" due to missing notifications
>
> I guess a revert of that commit should be done then..
>
> I have been stalling because I have been hoping to replace it with a
> better fix instead of a plain revert. I believe there are several issues
> playing badly together here.  That commit was _expected_ to cause
> spurious EPIPE errors, which would be translated to EIO if they were
> propagated.  But they should be filtered out rightaway, in theory. This
> works for me.  I can see the EPIPEs with debugging, but I have never
> seen any EIO from read.
>
> And there is the problem: I am unable to reproduce this problem.  I have
> previously tested this back and forth with several MDM9200 and MDM9235
> generation modems in QMI mode, as well as in MBIM mode.  And also with a
> number of other MBIM modems.  Aleksander reported that he could
> reproduce the issue using an MDM9x15 generation modem in QMI mode, but
> not with any MDM9x00 or MDM9x35 modem.  So I have now tried any way I
> can imagine to reproduce the issue with a Sierra Wireless EM7305, which
> is the only MDM9x15 modem I have. The firmware is SWI9X15C_05.05.58.00.
>
> But unfortunately the testing is still without "success".  It plain
> works for me, every time, using ModemManager, qmicli with or without
> proxy, or uqmi.
>
> Would you mind describing in detail how you trigger the EIOs?  What
> software and command sequence are you using?  Does it reliably reproduce
> the issue, or do you have to try several times?  What modem chipset and
> firmware is used?

Reliably, as in the second command I sent already showed the issue :/
I meant to try to debug this issue myself a while ago, but got busy
with other stuff, as usual... This is with a Sierra Wireless MC7304
running SWI9X15C_05.05.67.00. If you want, I can give you SSH access
to a system with this modem plugged in, or I can even send you a spare
MC7354, whatever you prefer.

I'm just running --dms-get-operating-mode multiple times, and getting
errors frequently:

aleksander@athena:~/Development/foss/libqmi:(master)$ sudo qmicli -d
/dev/cdc-wdm3 --dms-get-operating-mode
[/dev/cdc-wdm3] Operating mode retrieved:
Mode: 'online'
HW restricted: 'no'

aleksander@athena:~/Development/foss/libqmi:(master)$ sudo qmicli -d
/dev/cdc-wdm3 --dms-get-operating-mode
[19 abr 2017, 20:25:36] -Warning ** Error reading from istream: Error
reading from file descriptor: Input/output error
^[[A^Ccancelling the operation...
error: couldn't create client for the 'dms' service: Operation was cancelled

aleksander@athena:~/Development/foss/libqmi:(master)$ sudo qmicli -d
/dev/cdc-wdm3 --dms-get-operating-mode
[19 abr 2017, 20:25:38] -Warning ** Error reading from istream: Error
reading from file descriptor: Input/output error
^Ccancelling the operation...
error: couldn't create client for the 'dms' service: Operation was cancelled

aleksander@athena:~/Development/foss/libqmi:(master)$ sudo qmicli -d
/dev/cdc-wdm3 --dms-get-operating-mode
[/dev/cdc-wdm3] Operating mode retrieved:
Mode: 'online'
HW restricted: 'no'

aleksander@athena:~/Development/foss/libqmi:(master)$ sudo qmicli -d
/dev/cdc-wdm3 --dms-get-operating-mode
[/dev/cdc-wdm3] Operating mode retrieved:
Mode: 'online'
HW restricted: 'no'

aleksander@athena:~/Development/foss/libqmi:(master)$ sudo qmicli -d
/dev/cdc-wdm3 --dms-get-operating-mode
[/dev/cdc-wdm3] Operating mode retrieved:
Mode: 'online'
HW restricted: 'no'

aleksander@athena:~/Development/foss/libqmi:(master)$ sudo qmicli -d
/dev/cdc-wdm3 --dms-get-operating-mode
[/dev/cdc-wdm3] Operating mode retrieved:
Mode: 'online'
HW restricted: 'no'

aleksander@athena:~/Development/foss/libqmi:(master)$ sudo qmicli -d
/dev/cdc-wdm3 --dms-get-operating-mode
[19 abr 2017, 20:25:52] -Warning ** Error reading from istream: Error
reading from file descriptor: Input/output error
error: couldn't create client for the 'dms' service: CID allocation
failed in the CTL client: Transaction timed out

...

-- 
Aleksander
https://aleksander.es
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/1] drivers: net: usb: qmi_wwan: add QMI_QUIRK_SET_DTR for Telit PID 0x1201

[Bjørn Mork]

Aleksander Morgado <aleksander-Dvg4H30XQSRVIjRurl1/8g@public.gmane.org> writes:

> On Wed, Apr 19, 2017 at 7:28 PM, Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org> wrote:
>>> as a side note in latest kernels I had troubles with qmi devices
>>> (e.g. I/O error when using qmicli).
>>>
>>> I found your suggestion in libqmi mailing list to revert commit
>>>
>>> 833415a3e781a26fe480a34d45086bdb4fe1e4c0
>>> cdc-wdm: fix "out-of-sync" due to missing notifications
>>
>> I guess a revert of that commit should be done then..
>>
>> I have been stalling because I have been hoping to replace it with a
>> better fix instead of a plain revert. I believe there are several issues
>> playing badly together here.  That commit was _expected_ to cause
>> spurious EPIPE errors, which would be translated to EIO if they were
>> propagated.  But they should be filtered out rightaway, in theory. This
>> works for me.  I can see the EPIPEs with debugging, but I have never
>> seen any EIO from read.
>>
>> And there is the problem: I am unable to reproduce this problem.  I have
>> previously tested this back and forth with several MDM9200 and MDM9235
>> generation modems in QMI mode, as well as in MBIM mode.  And also with a
>> number of other MBIM modems.  Aleksander reported that he could
>> reproduce the issue using an MDM9x15 generation modem in QMI mode, but
>> not with any MDM9x00 or MDM9x35 modem.  So I have now tried any way I
>> can imagine to reproduce the issue with a Sierra Wireless EM7305, which
>> is the only MDM9x15 modem I have. The firmware is SWI9X15C_05.05.58.00.
>>
>> But unfortunately the testing is still without "success".  It plain
>> works for me, every time, using ModemManager, qmicli with or without
>> proxy, or uqmi.
>>
>> Would you mind describing in detail how you trigger the EIOs?  What
>> software and command sequence are you using?  Does it reliably reproduce
>> the issue, or do you have to try several times?  What modem chipset and
>> firmware is used?
>
> Reliably, as in the second command I sent already showed the issue :/
> I meant to try to debug this issue myself a while ago, but got busy
> with other stuff, as usual... This is with a Sierra Wireless MC7304
> running SWI9X15C_05.05.67.00. If you want, I can give you SSH access
> to a system with this modem plugged in, or I can even send you a spare
> MC7354, whatever you prefer.

I don't think another modem would help.  The EM7305 should be the same
as an.MC7304 or MC7354 in this regard.

And the ssh access would only help if I knew what to look for.  I think
you can do this just as well as me...  


> I'm just running --dms-get-operating-mode multiple times, and getting
> errors frequently:
>
> aleksander@athena:~/Development/foss/libqmi:(master)$ sudo qmicli -d
> /dev/cdc-wdm3 --dms-get-operating-mode
> [/dev/cdc-wdm3] Operating mode retrieved:
> Mode: 'online'
> HW restricted: 'no'
>
> aleksander@athena:~/Development/foss/libqmi:(master)$ sudo qmicli -d
> /dev/cdc-wdm3 --dms-get-operating-mode
> [19 abr 2017, 20:25:36] -Warning ** Error reading from istream: Error
> reading from file descriptor: Input/output error
> ^[[A^Ccancelling the operation...
> error: couldn't create client for the 'dms' service: Operation was cancelled

Lucky you :)

I upgraded the EM7305 to SWI9X15C_05.05.67.00 and tried again.  No
difference.  I ran

 for i in `seq 1 1000`; do qmicli -d /dev/cdc-wdm1 --dms-get-operating-mode; done

without a single error.  I guess I'll go for the revert.

But I think we need to do something about commit c1da59dad0eb as
well. It can end up calling usb_submit_urb(desc->response, GFP_KERNEL)
from an URB callback.  And making the rerr update conditional doesn't
seem right either.  It changes the meaning of rerr from "last status" to
"first error", which means that any error will mask a later success
until userspace reads the error.  That's fishy.


Bjørn



--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/1] drivers: net: usb: qmi_wwan: add QMI_QUIRK_SET_DTR for Telit PID 0x1201

[Bjørn Mork]

Aleksander Morgado <aleksander@aleksander.es> writes:

> I'm just running --dms-get-operating-mode multiple times, and getting
> errors frequently:

Could you retry that with cdc-wdm debugging enabled (e.g.
"echo 'module cdc_wdm +fp' > /sys/kernel/debug/dynamic_debug/control")
and something like this:


diff --git a/drivers/usb/class/cdc-wdm.c b/drivers/usb/class/cdc-wdm.c
index 8fda45a45bd3..c0f25ace9fc6 100644
--- a/drivers/usb/class/cdc-wdm.c
+++ b/drivers/usb/class/cdc-wdm.c
@@ -211,6 +211,8 @@ static void wdm_in_callback(struct urb *urb)
 		}
 	}
 
+	dev_dbg(&desc->intf->dev, "rerr=%d, status=%d, length=%d, resp_count=%d\n", desc->rerr, status, length, desc->resp_count);
+
 	/*
 	 * Handling devices with the WDM_DRAIN_ON_OPEN flag set:
 	 * If desc->resp_count is unset, then the urb was submitted
@@ -516,6 +518,9 @@ static ssize_t wdm_read
 		return -ERESTARTSYS;
 
 	cntr = ACCESS_ONCE(desc->length);
+
+	dev_dbg(&desc->intf->dev, "rerr=%d, length=%d\n", desc->rerr, cntr);
+
 	if (cntr == 0) {
 		desc->read = 0;
 retry:



And/or a usbmon dump?  That would be.probably show us the sequence of
events leading to this problem.

Desperately trying to figure out some other way to solve the issue that
commit  833415a3e781 ("cdc-wdm: fix "out-of-sync" due to missing
notifications") was supposed to fix....



Bjørn

Re: [PATCH 1/1] drivers: net: usb: qmi_wwan: add QMI_QUIRK_SET_DTR for Telit PID 0x1201

[Daniele Palmas]

Hi Bjørn,

2017-04-19 19:28 GMT+02:00 Bjørn Mork <bjorn@mork.no>:
> Daniele Palmas <dnlplm@gmail.com> writes:
>
>> as a side note in latest kernels I had troubles with qmi devices
>> (e.g. I/O error when using qmicli).
>>
>> I found your suggestion in libqmi mailing list to revert commit
>>
>> 833415a3e781a26fe480a34d45086bdb4fe1e4c0
>> cdc-wdm: fix "out-of-sync" due to missing notifications
>
> I guess a revert of that commit should be done then..
>
> I have been stalling because I have been hoping to replace it with a
> better fix instead of a plain revert. I believe there are several issues
> playing badly together here.  That commit was _expected_ to cause
> spurious EPIPE errors, which would be translated to EIO if they were
> propagated.  But they should be filtered out rightaway, in theory. This
> works for me.  I can see the EPIPEs with debugging, but I have never
> seen any EIO from read.
>
> And there is the problem: I am unable to reproduce this problem.  I have
> previously tested this back and forth with several MDM9200 and MDM9235
> generation modems in QMI mode, as well as in MBIM mode.  And also with a
> number of other MBIM modems.  Aleksander reported that he could
> reproduce the issue using an MDM9x15 generation modem in QMI mode, but
> not with any MDM9x00 or MDM9x35 modem.  So I have now tried any way I
> can imagine to reproduce the issue with a Sierra Wireless EM7305, which
> is the only MDM9x15 modem I have. The firmware is SWI9X15C_05.05.58.00.
>
> But unfortunately the testing is still without "success".  It plain
> works for me, every time, using ModemManager, qmicli with or without
> proxy, or uqmi.
>
> Would you mind describing in detail how you trigger the EIOs?  What
> software and command sequence are you using?  Does it reliably reproduce
> the issue, or do you have to try several times?  What modem chipset and
> firmware is used?
>

sorry for the delay, I'm using latest qmicli in master:

danielepa@danielepa-OptiPlex-780:~/development/git/libqmi$ src/qmicli/qmicli -V

qmicli 1.19.0

and I was able to reproduce the issue simply asking for something like
the manufacturer with qmicli.

But I'm currently retrying it and it has become even worse (do not ask
me why...): qmicli returns a transaction timed out error and got
stuck. Only when detaching the USB cable qmicli exits.

danielepa@danielepa-OptiPlex-780:~/development/git/libqmi$ sudo
src/qmicli/qmicli -d /dev/cdc-wdm0 --dms-get-manufacturer
[21 apr 2017, 12:15:33] -Warning ** [/dev/cdc-wdm0] requested auto
mode but no MBIM QMUX support available
error: couldn't create client for the 'dms' service: CID allocation
failed in the CTL client: Transaction timed out

I'm not sure I'm seeing here only problems related to your commit, but
reverting the commit makes things to work again.

The modem is a Telit LE920A4. I will try to collect more debug info.

Thanks,
Daniele

>
>
>
> Bjørn
>

Re: [PATCH 1/1] drivers: net: usb: qmi_wwan: add QMI_QUIRK_SET_DTR for Telit PID 0x1201

[Daniele Palmas]

Hi Bjørn,

2017-04-21 12:30 GMT+02:00 Daniele Palmas <dnlplm@gmail.com>:
> Hi Bjørn,
>
> 2017-04-19 19:28 GMT+02:00 Bjørn Mork <bjorn@mork.no>:
>> Daniele Palmas <dnlplm@gmail.com> writes:
>>
>>
>> Would you mind describing in detail how you trigger the EIOs?  What
>> software and command sequence are you using?  Does it reliably reproduce
>> the issue, or do you have to try several times?  What modem chipset and
>> firmware is used?
>>
>
> sorry for the delay, I'm using latest qmicli in master:
>
> danielepa@danielepa-OptiPlex-780:~/development/git/libqmi$ src/qmicli/qmicli -V
>
> qmicli 1.19.0
>
> and I was able to reproduce the issue simply asking for something like
> the manufacturer with qmicli.
>
> But I'm currently retrying it and it has become even worse (do not ask
> me why...): qmicli returns a transaction timed out error and got
> stuck. Only when detaching the USB cable qmicli exits.
>
> danielepa@danielepa-OptiPlex-780:~/development/git/libqmi$ sudo
> src/qmicli/qmicli -d /dev/cdc-wdm0 --dms-get-manufacturer
> [21 apr 2017, 12:15:33] -Warning ** [/dev/cdc-wdm0] requested auto
> mode but no MBIM QMUX support available
> error: couldn't create client for the 'dms' service: CID allocation
> failed in the CTL client: Transaction timed out
>
> I'm not sure I'm seeing here only problems related to your commit, but
> reverting the commit makes things to work again.
>
> The modem is a Telit LE920A4. I will try to collect more debug info.
>

So, I applied your debug patch and this is what is happening:

[ 4294.935912] usb 2-2: new high-speed USB device number 18 using ehci-pci
[ 4295.101548] usb 2-2: New USB device found, idVendor=1bc7, idProduct=1201
[ 4295.101551] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 4295.101553] usb 2-2: Product: Android
[ 4295.101555] usb 2-2: Manufacturer: Android
[ 4295.101557] usb 2-2: SerialNumber: 0123456789ABCDEF
[ 4295.118159] option 2-2:1.0: GSM modem (1-port) converter detected
[ 4295.118280] usb 2-2: GSM modem (1-port) converter now attached to ttyUSB0
[ 4295.119265] qmi_wwan 2-2:1.2: cdc-wdm0: USB WDM device
[ 4295.120387] qmi_wwan 2-2:1.2 wwan0: register 'qmi_wwan' at
usb-0000:00:1d.7-2, WWAN/QMI device, fe:b2:dd:b6:d5:b3
[ 4295.120464] option 2-2:1.3: GSM modem (1-port) converter detected
[ 4295.120555] usb 2-2: GSM modem (1-port) converter now attached to ttyUSB1
[ 4295.120643] option 2-2:1.4: GSM modem (1-port) converter detected
[ 4295.120699] usb 2-2: GSM modem (1-port) converter now attached to ttyUSB2
[ 4295.120785] option 2-2:1.5: GSM modem (1-port) converter detected
[ 4295.120839] usb 2-2: GSM modem (1-port) converter now attached to ttyUSB3
[ 4295.120923] option 2-2:1.6: GSM modem (1-port) converter detected
[ 4295.120978] usb 2-2: GSM modem (1-port) converter now attached to ttyUSB4
[ 4306.730786] wdm_open: qmi_wwan 2-2:1.2: draining queued data
[ 4306.730955] wdm_write: qmi_wwan 2-2:1.2: Tx URB has been submitted index=2

Here qmicli is stuck. Then I disconnect the cable:

[ 4421.317327] usb 2-2: USB disconnect, device number 18
[ 4421.317541] option1 ttyUSB0: GSM modem (1-port) converter now
disconnected from ttyUSB0
[ 4421.317558] option 2-2:1.0: device disconnected
[ 4421.320113] qmi_wwan 2-2:1.2 wwan0: unregister 'qmi_wwan'
usb-0000:00:1d.7-2, WWAN/QMI device
[ 4421.321297] qmi_wwan 2-2:1.2: Unexpected error -71
[ 4421.321303] wdm_in_callback: qmi_wwan 2-2:1.2: rerr=-71,
status=-71, length=0, resp_count=0
[ 4421.325567] qmi_wwan 2-2:1.2: Error in flush path: -71
[ 4421.325579] wdm_release: qmi_wwan 2-2:1.2: wdm_release: cleanup
[ 4421.335695] option1 ttyUSB1: GSM modem (1-port) converter now
disconnected from ttyUSB1
[ 4421.335710] option 2-2:1.3: device disconnected
[ 4421.335838] option1 ttyUSB2: GSM modem (1-port) converter now
disconnected from ttyUSB2
[ 4421.335850] option 2-2:1.4: device disconnected
[ 4421.335972] option1 ttyUSB3: GSM modem (1-port) converter now
disconnected from ttyUSB3
[ 4421.335984] option 2-2:1.5: device disconnected
[ 4421.336175] option1 ttyUSB4: GSM modem (1-port) converter now
disconnected from ttyUSB4
[ 4421.336187] option 2-2:1.6: device disconnected

This is instead the output with the commit reverted:

[ 9868.397535] usb 2-2: new high-speed USB device number 19 using ehci-pci
[ 9868.563187] usb 2-2: New USB device found, idVendor=1bc7, idProduct=1201
[ 9868.563189] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 9868.563191] usb 2-2: Product: Android
[ 9868.563193] usb 2-2: Manufacturer: Android
[ 9868.563195] usb 2-2: SerialNumber: 0123456789ABCDEF
[ 9868.579788] option 2-2:1.0: GSM modem (1-port) converter detected
[ 9868.579920] usb 2-2: GSM modem (1-port) converter now attached to ttyUSB0
[ 9868.580559] option 2-2:1.3: GSM modem (1-port) converter detected
[ 9868.580629] usb 2-2: GSM modem (1-port) converter now attached to ttyUSB1
[ 9868.580721] option 2-2:1.4: GSM modem (1-port) converter detected
[ 9868.580778] usb 2-2: GSM modem (1-port) converter now attached to ttyUSB2
[ 9868.580859] option 2-2:1.5: GSM modem (1-port) converter detected
[ 9868.580915] usb 2-2: GSM modem (1-port) converter now attached to ttyUSB3
[ 9868.580995] option 2-2:1.6: GSM modem (1-port) converter detected
[ 9868.581048] usb 2-2: GSM modem (1-port) converter now attached to ttyUSB4
[ 9868.603054] usbcore: registered new interface driver cdc_wdm
[ 9868.605852] qmi_wwan 2-2:1.2: cdc-wdm0: USB WDM device
[ 9868.606547] qmi_wwan 2-2:1.2 wwan0: register 'qmi_wwan' at
usb-0000:00:1d.7-2, WWAN/QMI device, fe:b2:dd:b6:d5:b3
[ 9868.606674] usbcore: registered new interface driver qmi_wwan
[ 9885.295723] wdm_write: qmi_wwan 2-2:1.2: Tx URB has been submitted index=2
[ 9885.296210] wdm_int_callback: qmi_wwan 2-2:1.2:
NOTIFY_NETWORK_CONNECTION disconnected from network
[ 9885.328208] wdm_int_callback: qmi_wwan 2-2:1.2:
NOTIFY_RESPONSE_AVAILABLE received: index 2 len 0
[ 9885.328216] wdm_int_callback: qmi_wwan 2-2:1.2: submit response URB 0
[ 9885.329166] wdm_write: qmi_wwan 2-2:1.2: Tx URB has been submitted index=2
[ 9885.360203] wdm_int_callback: qmi_wwan 2-2:1.2:
NOTIFY_RESPONSE_AVAILABLE received: index 2 len 0
[ 9885.360210] wdm_int_callback: qmi_wwan 2-2:1.2: submit response URB 0
[ 9885.361463] wdm_write: qmi_wwan 2-2:1.2: Tx URB has been submitted index=2
[ 9885.392210] wdm_int_callback: qmi_wwan 2-2:1.2:
NOTIFY_RESPONSE_AVAILABLE received: index 2 len 0
[ 9885.392221] wdm_int_callback: qmi_wwan 2-2:1.2: submit response URB 0
[ 9885.393370] wdm_release: qmi_wwan 2-2:1.2: wdm_release: cleanup

If needed I can try to collect usbmon.

Regards,
Daniele

> Thanks,
> Daniele
>
>>
>>
>>
>> Bjørn
>>

Re: [PATCH 1/1] drivers: net: usb: qmi_wwan: add QMI_QUIRK_SET_DTR for Telit PID 0x1201

[Bjørn Mork]

Daniele Palmas <dnlplm@gmail.com> writes:

> So, I applied your debug patch and this is what is happening:

Thanks

> [ 4306.730786] wdm_open: qmi_wwan 2-2:1.2: draining queued data
> [ 4306.730955] wdm_write: qmi_wwan 2-2:1.2: Tx URB has been submitted index=2
>
> Here qmicli is stuck. Then I disconnect the cable:

I guess this modem dislikes the unsolicted IN control request so much
that it ignores the OUT control request. I have a feeling that this is
violating the USB spec, since a STALL on the control pipe is supposed to
be cleared by the next setup.

But either way, we have to just accept whatever the device does.


> This is instead the output with the commit reverted:
..
> [ 9885.295723] wdm_write: qmi_wwan 2-2:1.2: Tx URB has been submitted index=2
> [ 9885.296210] wdm_int_callback: qmi_wwan 2-2:1.2: NOTIFY_NETWORK_CONNECTION disconnected from network
> [ 9885.328208] wdm_int_callback: qmi_wwan 2-2:1.2: NOTIFY_RESPONSE_AVAILABLE received: index 2 len 0
> [ 9885.328216] wdm_int_callback: qmi_wwan 2-2:1.2: submit response URB 0


I note that you get a NETWORK_CONNECTION notification here, which you
also did not receive in the failing case.  That's interesting.  Another
indication that the device is completely stuck as a result of the IN
control request.

Thanks for this.  It shows that we can forget about any such automatic
queue flushing for QMI devices. Any reimplementation of this feature
must be limited to CDC MBIM. The "queue-out-of-sync" issue is mostly
affecting Intel MBIM devices anyway.



Bjørn