On Mon, 21 Sep 2009, Oliver Neukum wrote:
> Am Montag, 21. September 2009 18:29:32 schrieb Nicolas Chevillot:
> > Oliver,
> >
> > I have been investigating the reasons why our device does not work well
> > with USB Autosuspend while using ECM.
> >
> > I used a USB Analyzer to trace the USB activity and found out that after
> > the SetFeature(Device Remote-Wakeup) transfer that precedes USB Suspend,
> > an IN token is received on EP6 which is the Bulk IN used by ECM.
> >
> > We know there is a bug in the USB PHY we use that puts our system in a
> > locked state when NAK is sent prior to enter USB Suspend.
> > In any case, the IN EP6 IN token should not be sent after the host sends
> > SetFeature(Device Remote-Wakeup).
> >
> > Do you have any idea where this additional IN EP6 IN could come from?
> > And if it would be easy to patch?
>
> I have no idea whence the IN comes. REMOTE_WAKEUP is the last thing
> that's requested before the parent's port is suspended:
>
> if (udev->do_remote_wakeup) {
> status = usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
> USB_REQ_SET_FEATURE, USB_RECIP_DEVICE,
> USB_DEVICE_REMOTE_WAKEUP, 0,
> NULL, 0,
> USB_CTRL_SET_TIMEOUT);
> if (status)
> dev_dbg(&udev->dev, "won't remote wakeup, status %d\n",
> status);
> }
>
> /* see 7.1.7.6 */
> status = set_port_feature(hub->hdev, port1, USB_PORT_FEAT_SUSPEND);
>
> Can you verify all URBs are unlinked before the device is supended? On a hunch
> put an medelay(50) into usbnet_suspend right before the return statement.
It wouldn't hurt to collect a usbmon trace showing everything from
plug-in to suspend. That would let us verify whether all the URBs
really had been cancelled.
Alan Stern
--
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
