> Oh. I recheck find these device will use ordinary resume rather than > reset_resume(). > I remeber you said userspace should set USB_QUIRK_RESET_MORPHS for those > kind devices. After reset, they will morph. So reset_resume doesn't > work for them. > Ordinary resume almost just calls usb_get_status(udev, USB_RECIP_DEVICE, 0, > &devstatus) to verify whether usb device is OK. So even the device has been > repowered. Resume will be sucessful even the interface is changed. So > I have idea > to add a verify_resume without reset for these kind devices. Check > whether device class > was changed or interface vanish .If it morphed, then return error and > then renumerate then. > Does this make sense? If you have powered off the port during the suspend, the device will be at powered state after resume, the usb_get_status will be failed, even you skip the result of usb_get_status, the coming operation for that device will also be failed as the device address for itself returns to 0, but host doesn't know it. If port power is off (for bus powered device), the reset is the only way to let the device work again.
>> >> >> > The driver loaded again with firmware and the device still could work, is >> > Right? >> >> No. All settings user space has done will be lost. > > Can we notify user space to reconfigue it? Or they will find original > device have removed > and new device is coming. Reconfigue the new device. Because the > device is renumerated > during this procedure. > > -- > Best regards > Lan Tianyu > -- > To unsubscribe from this list: send the line "unsubscribe linux-usb" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
