On Thu, Jul 17, 2014 at 05:55:22PM +0800, Pratyush Anand wrote:
> Hi David,
>
> On Thu, Jul 17, 2014 at 05:37:44PM +0800, David Laight wrote:
> > From: Pratyush Anand
> > ...
> > > Only side effect of long timeout: If a device was connected before
> > > suspend, and was removed while system was as
On Thu, 17 Jul 2014, David Laight wrote:
> From: Pratyush Anand
> ...
> > 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
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
Hi David,
On Thu, Jul 17, 2014 at 05:37:44PM +0800, David Laight wrote:
> From: Pratyush Anand
> ...
> > 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
From: Pratyush Anand
...
> 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.
...
Can't you use the
Hi Alan,
On Wed, Jul 16, 2014 at 10:05:57PM +0800, Alan Stern wrote:
> On Wed, 16 Jul 2014, Pratyush Anand wrote:
>
> > Hu..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 ch
On Wed, 16 Jul 2014, Pratyush Anand wrote:
> Hu..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 t
On Wed, Jul 16, 2014 at 01:25:21PM +0800, Pratyush Anand wrote:
> Hi Alan,
>
> Thanks a lot for your review.
>
> On Tue, Jul 15, 2014 at 10:46:00PM +0800, Alan Stern wrote:
> > On Tue, 15 Jul 2014, Pratyush Anand wrote:
> >
> > > Problem Summary: Problem has been observed generally with PM states
Hi David,
Thanks for your review.
On Tue, Jul 15, 2014 at 10:58:03PM +0800, David Laight wrote:
> From: Alan Stern
> > On Tue, 15 Jul 2014, Pratyush Anand wrote:
> ...
> > > +static int wait_for_ss_port_enable(struct usb_device *udev,
> > > + struct usb_hub *hub,
>
Hi Alan,
Thanks a lot for your review.
On Tue, Jul 15, 2014 at 10:46:00PM +0800, Alan Stern wrote:
> On Tue, 15 Jul 2014, Pratyush Anand wrote:
>
> > Problem Summary: Problem has been observed generally with PM states
> > where VBUS goes off during suspend. There are some SS USB devices which
>
From: Alan Stern
> On Tue, 15 Jul 2014, Pratyush Anand wrote:
...
> > +static int wait_for_ss_port_enable(struct usb_device *udev,
> > + struct usb_hub *hub,
> > + int *port1,
> > + u16 *portchange
On Tue, 15 Jul 2014, Pratyush Anand wrote:
> Problem Summary: Problem has been observed generally with PM states
> where VBUS goes off during suspend. There are some SS USB devices which
> takes slightly longer time for link training compared to many others.
> Such devices fails to reconnect with
Problem Summary: Problem has been observed generally with PM states
where VBUS goes off during suspend. There are some SS USB devices which
takes slightly longer time for link training compared to many others.
Such devices fails to reconnect with same old address which was
associated with it before
13 matches
Mail list logo
