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.
Regards
Oliver
--
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
