Bjørn Mork <bjorn@xxxxxxx> writes: > Oliver Neukum <oneukum@xxxxxxx> writes: > >> On Wednesday 10 October 2012 18:34:52 Bjørn Mork wrote: >>> Signed-off-by: Bjørn Mork <bjorn@xxxxxxx> >>> --- >>> What do you think about something like this? Does it have to >>> be more complicated? Somewhat tested, and seems to do the >>> job for me. >> >> Looks good. Which minidriver did you test with? > > Thanks for reviewing it. I'll test a bit more with other drivers and > submit it then. I have now tested it with qmi_wwan, using Sierra Wireless MC7710 and Huawei E367u-2 rndis_host, using a Samsung Galaxy 8.9 LTE with Android 3.2 cdc_ncm, using an Ericsson F5521gw The qmi_wwan and rndis_host tests were OK, keeping an active connection up and running over the USB reset. Even the mode switching Huawei device survived this for some reason. I guess that depends on how the firmware interpretes "reset". The cdc_ncm test was not entirely successful. The Ericsson device disconnects the active session on reset: Oct 11 10:25:31 nemi kernel: [42965.212151] usb 2-1: reset high-speed USB device number 13 using ehci_hcd Oct 11 10:25:31 nemi kernel: [42965.382001] cdc_ncm 2-1:1.6: wwan2: rxqlen 0 --> 10 Oct 11 10:25:31 nemi kernel: [42965.382017] cdc_ncm 2-1:1.6: wwan2: rxqlen 10 --> 11 Oct 11 10:25:31 nemi kernel: [42965.392019] cdc_ncm: wwan2: network connection: connected Oct 11 10:25:31 nemi kernel: [42965.400037] cdc_ncm: wwan2: network connection: disconnected And then the driver is out of sequence if you bring up the connection again: Oct 11 10:26:48 nemi kernel: [43042.144886] cdc_ncm: wwan2: 21 mbit/s downlink 5 mbit/s uplink Oct 11 10:26:48 nemi kernel: [43042.152877] cdc_ncm: wwan2: network connection: connected Oct 11 10:26:50 nemi kernel: [43044.112325] sequence number glitch prev=267 curr=0 This is harmless because the driver ignores the sequence numbers anyway. But if the disconnect on reset is typical for NCM devices, then I guess it does not help much adding pre and post_reset in cdc_ncm. So I guess that demonstrates the issue with pre and post_reset on devices keeping internal state pretty well: The effect is entirely device dependent. The device reset behaviour is not known, and we risk that the device changes some of its internal variables on reset. So adding reset support to class minidrivers is risky. Although my rndis_host test worked, there is no guarantee that other rndis devices will work the same way. What do we do? Drop it? Add the support to usbnet and use it only where "safe"? Add it and implement it in any minidriver using plain usbnet suspend and resume, possibly adding device quirks later? I believe qmi_wwan is a candidate for unconditional reset support because all supported devices are based on the same chipset family using the same chipset vendor firmware as a basis. And there is some benefit, as these devices often expose a usb-storage interface in modem mode as well. Bjørn -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
