On Wed, 2016-02-03 at 11:24 -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 <oneu...@suse.com>
> > CC: sta...@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;
Indeed. Greg, I'll make an improved patch.
Regards
Oliver
--
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
