From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f182.google.com ([209.85.192.182]:33531 "EHLO mail-pf0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752559AbcBDG5O (ORCPT ); Thu, 4 Feb 2016 01:57:14 -0500 Date: Thu, 4 Feb 2016 14:53:26 +0800 From: Peter Chen To: Alan Stern Cc: Oliver Neukum , gregkh@linuxfoundation.org, linux-usb@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH] usb: retry reset if a device times out Message-ID: <20160204065326.GC11158@shlinux2> References: <1454496464-13094-1-git-send-email-oneukum@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: stable-owner@vger.kernel.org List-ID: On Wed, Feb 03, 2016 at 11:24:57AM -0500, Alan Stern wrote: > On Wed, 3 Feb 2016, Oliver Neukum wrote: > > > Some devices I got show an inability to operate right after > > power on if they are already connected. They are beyond recovery > > if the descriptors are requested multiple times. So in case of > > a timeout we rather bail early and reset again. > > > > This patch is a rework of a patch that fell through the cracks. > > http://www.spinics.net/lists/linux-usb/msg103263.html > > > > Signed-off-by: Oliver Neukum > > CC: stable@vger.kernel.org > > --- > > drivers/usb/core/hub.c | 7 ++++++- > > 1 file changed, 6 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c > > index f912fe6..2124c4e 100644 > > --- a/drivers/usb/core/hub.c > > +++ b/drivers/usb/core/hub.c > > @@ -4496,7 +4496,12 @@ hub_port_init(struct usb_hub *hub, struct usb_device *udev, int port1, > > r = -EPROTO; > > break; > > } > > - if (r == 0) > > + /* > > + * Some devices time out if they are powered on > > + * when already connected. They need a second > > + * reset. > > + */ > > + if (r == 0 || r == -ETIMEDOUT) > > break; > > } > > udev->descriptor.bMaxPacketSize0 = > > > > Hmmm. Your device fails completely if there are multiple attempts > without a reset in between, right? > > What about devices which always time out the first control request > after a reset? I can't be certain any such devices exist, but it > wouldn't be surprising given the range of hardware bugs in USB devices. > > Would it be safer to do this instead? > > if (r == 0 || (r == -ETIMEDOUT && > j = 0)) > break; > Alan, you may want to skip the first timeout, but quit at the second timeout, right? If it is, the code may need to change like below: if (r == 0 || (r == -ETIMEDOUT && j != 0)) -- Best Regards, Peter Chen