Re: [PATCH] usbnet: prevent device rpm suspend in usbnet_probe function

3 messages, 3 authors, 2016-11-09 · open the first message on its own page

Re: [PATCH] usbnet: prevent device rpm suspend in usbnet_probe function

From: Bjørn Mork <bjorn@mork.no>
Date: 2016-11-08 16:50:48

Alan Stern [off-list ref] writes:
On Tue, 8 Nov 2016, Kai-Heng Feng wrote:
quoted
Hi,

On Mon, Nov 7, 2016 at 7:02 PM, Oliver Neukum [off-list ref] wrote:
quoted
On Fri, 2016-11-04 at 17:57 +0800, Kai-Heng Feng wrote:
quoted
Sometimes cdc_mbim failed to probe if runtime pm is enabled:
[    9.305626] cdc_mbim: probe of 2-2:1.12 failed with error -22

This can be solved by increase its pm usage counter.

Signed-off-by: Kai-Heng Feng <redacted>
For the record:

NAK. This fixes a symptom. If this patch helps something is broken in
device core. We need to find that.
Please check attached dmesg with usbcore.dyndbg="+p".
The log shows that the device went into suspend _before_ the cdc_mbim 
driver was probed, not during the probe.  Then just before the probe 
was started, the USB core tried to resume the device and the resume 
failed.

The log shows a bunch of other problems with this device:

[    3.862253] usb 2-2: config 1 has an invalid interface number: 12 but max is 1
[    3.862254] usb 2-2: config 1 has an invalid interface number: 13 but max is 1
[    3.862254] usb 2-2: config 1 has an invalid interface number: 13 but max is 1
[    3.862255] usb 2-2: config 1 has no interface number 0
[    3.862256] usb 2-2: config 1 has no interface number 1
These messages are completely harmless and normal for Sierra Wireless
devices.  They use the interface number to identify the type of
function, causing this mismatch between the number of interfaces and the
inteface numbers. Boy, that looks weird in writing :)

Ref this discussion we had a few years ago:
http://www.spinics.net/lists/linux-usb/msg77499.html

No, I didn't expect you to remember that :)

[    8.295180] usb 2-2: Disable of device-initiated U1 failed.
[    8.295322] usb 2-2: Disable of device-initiated U2 failed.

I get the impression that the device won't work properly with runtime 
PM at all.
I suspect the device is an EM7455?  If so, then it does work fine with
runtime PM, as long as we're talking USB2.  Not sure about USB3 runtime
PM though.  Cannot test it. The Lenovo laptop I got with one of these
modems has disabled the USB3 link on the m.2 modem slot for some reason.


Bjørn

Re: [PATCH] usbnet: prevent device rpm suspend in usbnet_probe function

From: Alan Stern <stern@rowland.harvard.edu>
Date: 2016-11-08 18:44:11

On Tue, 8 Nov 2016, Bjørn Mork wrote:
Alan Stern [off-list ref] writes:
quoted
On Tue, 8 Nov 2016, Kai-Heng Feng wrote:
quoted
Hi,

On Mon, Nov 7, 2016 at 7:02 PM, Oliver Neukum [off-list ref] wrote:
quoted
On Fri, 2016-11-04 at 17:57 +0800, Kai-Heng Feng wrote:
quoted
Sometimes cdc_mbim failed to probe if runtime pm is enabled:
[    9.305626] cdc_mbim: probe of 2-2:1.12 failed with error -22

This can be solved by increase its pm usage counter.

Signed-off-by: Kai-Heng Feng <redacted>
For the record:

NAK. This fixes a symptom. If this patch helps something is broken in
device core. We need to find that.
Please check attached dmesg with usbcore.dyndbg="+p".
The log shows that the device went into suspend _before_ the cdc_mbim 
driver was probed, not during the probe.  Then just before the probe 
was started, the USB core tried to resume the device and the resume 
failed.

The log shows a bunch of other problems with this device:

[    3.862253] usb 2-2: config 1 has an invalid interface number: 12 but max is 1
[    3.862254] usb 2-2: config 1 has an invalid interface number: 13 but max is 1
[    3.862254] usb 2-2: config 1 has an invalid interface number: 13 but max is 1
[    3.862255] usb 2-2: config 1 has no interface number 0
[    3.862256] usb 2-2: config 1 has no interface number 1
These messages are completely harmless and normal for Sierra Wireless
devices.  They use the interface number to identify the type of
function, causing this mismatch between the number of interfaces and the
inteface numbers. Boy, that looks weird in writing :)

Ref this discussion we had a few years ago:
http://www.spinics.net/lists/linux-usb/msg77499.html

No, I didn't expect you to remember that :)
You're right; I didn't remember it.  But seeing those messages again in
the mailing list archives, they do look a little familiar.
quoted
[    8.295180] usb 2-2: Disable of device-initiated U1 failed.
[    8.295322] usb 2-2: Disable of device-initiated U2 failed.

I get the impression that the device won't work properly with runtime 
PM at all.
I suspect the device is an EM7455?  If so, then it does work fine with
runtime PM, as long as we're talking USB2.  Not sure about USB3 runtime
PM though.  Cannot test it. The Lenovo laptop I got with one of these
modems has disabled the USB3 link on the m.2 modem slot for some reason.
These problems could very well be caused by running at SuperSpeed
(USB-3) instead of high speed (USB-2).

Is there any way to test what happens when the device is attached to 
the computer by a USB-2 cable?  That would prevent it from operating at 
SuperSpeed.

The main point, however, is that the proposed patch doesn't seem to
address the true problem, which is that the device gets suspended
between probes.  The patch only tries to prevent it from being
suspended during a probe -- which is already prevented by the USB core.

Alan Stern

Re: [PATCH] usbnet: prevent device rpm suspend in usbnet_probe function

From: Oliver Neukum <oneukum@suse.com>
Date: 2016-11-09 12:04:47

On Tue, 2016-11-08 at 13:44 -0500, Alan Stern wrote:
These problems could very well be caused by running at SuperSpeed
(USB-3) instead of high speed (USB-2).

Is there any way to test what happens when the device is attached to 
the computer by a USB-2 cable?  That would prevent it from operating at 
SuperSpeed.

The main point, however, is that the proposed patch doesn't seem to
address the true problem, which is that the device gets suspended
between probes.  The patch only tries to prevent it from being
suspended during a probe -- which is already prevented by the USB core.
But why doesn't it fail during normal operation?

I suspect that its firmware requires the altsetting

        /* should we change control altsetting on a NCM/MBIM function? */
        if (cdc_ncm_select_altsetting(intf) == CDC_NCM_COMM_ALTSETTING_MBIM) {
                data_altsetting = CDC_NCM_DATA_ALTSETTING_MBIM;
                ret = cdc_mbim_set_ctrlalt(dev, intf, CDC_NCM_COMM_ALTSETTING_MBIM);

to be set before it accepts a suspension.

	Regards
		Oliver
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help