Hello Joe, On Wed, Nov 05, 2014 at 06:20:06AM +0800, Joseph Salisbury wrote: > Hello Pratyush, > > A kernel bug report was opened against Ubuntu [0]. After a kernel > bisect, it was found that reverting the following commit resolved this bug: > > commit a40178b2fa6ad87670fb1e5fa4024db00c149629 > Author: Pratyush Anand <pratyush.anand@xxxxxx> > Date: Fri Jul 18 12:37:10 2014 +0530 > > USB: Fix persist resume of some SS USB devices > > The regression was introduced as of v3.17-rc1. The regression still > exists in the 3.18-rc3 mainline kernel, and has made it's way into the > stable kernels. Its strange, as per my understanding patch does not introduce any side effect for devices whose resume time is normal. So, if a device is connected to the SS port and it was working after resume from suspend to ram without this patch, then that device should still work with this patch. Infact this has resolved another bug reported to bugzilla https://bugzilla.kernel.org/show_bug.cgi?id=53211 > > I was hoping to get your feedback, since you are the patch author. Do > you think gathering any additional data will help diagnose this issue, Yaa, sure additional info will help to understand the issue. -- dmesg log of suspend resume when this patch is not applied and also when applied. -- dmesg log with following additional debug print. @@ -3318,6 +3318,7 @@ static int wait_for_ss_port_enable(struct usb_device *udev, int status = 0, delay_ms = 0; while (delay_ms < 2000) { + printk("%s:portstatus is %x and portchange is %x\n", __func__, *portstatus, *portchange); if (status || *portstatus & USB_PORT_STAT_CONNECTION) break; > or would it be best to submit a revert request? Let me see what is the portstatus value and why didn't it break loop in first iteration if device was OK. Regards Pratyush > > > Thanks, > > Joe > > [0] http://pad.lv/1384041 -- 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
