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
12 matches
Mail list logo
