Hi Alan,
On Wed, Jul 16, 2014 at 10:05:57PM +0800, Alan Stern wrote:
> On Wed, 16 Jul 2014, Pratyush Anand wrote:
>
> > Hummmm..May be this solution is not perfect. Have been reported with
> > at least one device which failed with this patch too. A print of
> > link_state for that device(sleep changed to 2ms) shows that for a long
> > time link was in rxDetect. May be I will try to see with analyzer what
> > exactly happens with such devices.
> >
> > Giving 2nd thought to timeout calculation: Probably we can not
> > calculate timeout by adding all substates timeout. It would be valid
> > only when link does not go back in the state machine. For example, it
> > might happen that host is in polling.active and it did not receive
> > sufficient number of TS2 in tPollingActiveTimeout and so it moves
> > backward to polling.LFPS. But next time when state machine advances,
> > it is able to reach to U0. So the total time may be more than 400 mS
> > and a successful linkup. Device which failed with this patch worked
> > with 2000 ms timeout :( Not sure how can we manage timeout.
>
> 2 seconds seems like too long to wait. I don't understand why USB-3
> links take so long to train.
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 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;
}
~Pratyush
--
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
