On Thu, 17 Jul 2014, Pratyush Anand wrote:
> I got one sony usb stick (054C:05B8) which does not take 2S but
> certainly it takes more than 400 ms. I took the analyzer log with this
> device..and it tells me that this device is not behaving the right
> way. See the attached snapshot:
>
> -- Host does VBUS ON at 11.737 mS and within some microsecond it also
> does termination ON.
> -- It took almost 638 ms after VBUS ON for device to switch on the
> termination.
> -- So for these 638 ms, host LTSSM would have kept on switching
> between rxDetect.Quiet and rxDetect.Active. If SW reads XHCI port
> status for this duration, it will always show link in the rxdetect
> state.
>
> With another usb disk I observed that device fails to negotiate link
> training in first attempt. However, successful link training happens
> in second attempt.
>
> So the question remains, what should be the timeout? I think we should
> go with 2S timeout to support all the buggy devices reported so far.
>
> For the good device overhead is almost none. While for the bad devices
> penalty could be the time which it take for link training.
>
> Only side effect of long timeout: If a device was connected before
> suspend, and was removed while system was asleep, then the penalty
> would be the timeout ie 2000 ms. I do not see a way to handle this. I
> can put a FIXME note for this in patch.
I really don't like that side effect, but if it's the only way to make
these buggy devices work then there's no alternative.
> I think we should go with wait loop as follows, let me know your
> opinion.
>
> static int wait_for_ss_port_enable(struct usb_device *udev,
> struct usb_hub *hub, int *port1,
> u16 *portchange, u16 *portstatus)
> {
> int status = 0, delay_ms = 0;
>
> while (delay_ms < 2000) {
> if (status || *portstatus & USB_PORT_STAT_CONNECTION)
> break;
> msleep(20);
> delay_ms += 20;
> status = hub_port_status(hub, *port1, portstatus, portchange);
> }
> return status;
> }
Looks okay.
Alan Stern
--
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
