On Tue, Aug 06, 2013 at 01:05:40PM -0400, Alan Stern wrote:
> On Wed, 7 Aug 2013, Huang Rui wrote:
>
> > > > Could you explain that how can you make sure the root cause is unable
> > > > to relay wakup requests from downstream port to upstream port if
> > > > downstream port's suspend feature is n
On Wed, 7 Aug 2013, Huang Rui wrote:
> > > Got it, but I'm still a little confused. For example, one mouse is
> > > attached at usb2.0 port of roothub, and it supports remote wakeup. But
> > > the wakeup attribute is disabled for mouse defaultly, am I right? So
> >
> > Yes.
> >
> > > remote wake
On Wed, Aug 07, 2013 at 01:05:40AM +0800, Alan Stern wrote:
> On Wed, 7 Aug 2013, Huang Rui wrote:
>
> > > > Could you explain that how can you make sure the root cause is unable
> > > > to relay wakup requests from downstream port to upstream port if
> > > > downstream port's suspend feature is n
On Wed, 7 Aug 2013, Huang Rui wrote:
> > > Could you explain that how can you make sure the root cause is unable
> > > to relay wakup requests from downstream port to upstream port if
> > > downstream port's suspend feature is not set? The OS is unable wakeup
> > > from S3 at that time. We can't f
On Mon, Aug 05, 2013 at 10:10:27AM -0400, Alan Stern wrote:
> On Mon, 5 Aug 2013, Huang Rui wrote:
>
> > Hi Alan,
> >
> > On Thu, Jul 11, 2013 at 02:58:04PM -0400, Alan Stern wrote:
> > > The hub driver was recently changed to use "global" suspend for system
> > > suspend transitions on non-Super
On Mon, 5 Aug 2013, Huang Rui wrote:
> Hi Alan,
>
> On Thu, Jul 11, 2013 at 02:58:04PM -0400, Alan Stern wrote:
> > The hub driver was recently changed to use "global" suspend for system
> > suspend transitions on non-SuperSpeed buses. This means that we don't
> > suspend devices individually by
Hi Alan,
On Thu, Jul 11, 2013 at 02:58:04PM -0400, Alan Stern wrote:
> The hub driver was recently changed to use "global" suspend for system
> suspend transitions on non-SuperSpeed buses. This means that we don't
> suspend devices individually by setting the suspend feature on the
> upstream hub
On Fri, Jul 12, 2013 at 10:57:25AM -0400, Alan Stern wrote:
> On Fri, 12 Jul 2013, Peter Chen wrote:
>
>
> > - For hub cases, since you said it must send suspend to hub at
> > global suspend case (system suspend procedure), this suspend
> > request procedure can't be skipped.
>
> No -- it is nec
On Fri, 12 Jul 2013, Peter Chen wrote:
> On Thu, Jul 11, 2013 at 02:58:04PM -0400, Alan Stern wrote:
> > The hub driver was recently changed to use "global" suspend for system
> > suspend transitions on non-SuperSpeed buses. This means that we don't
> > suspend devices individually by setting the
On Thu, Jul 11, 2013 at 02:58:04PM -0400, Alan Stern wrote:
> The hub driver was recently changed to use "global" suspend for system
> suspend transitions on non-SuperSpeed buses. This means that we don't
> suspend devices individually by setting the suspend feature on the
> upstream hub port; ins
On Thu, 11 Jul 2013, Toralf Förster wrote:
> On 07/11/2013 08:58 PM, Alan Stern wrote:
> > This should be applied to the 3.10 stable kernel.
> >
> > Signed-off-by: Alan Stern
> > Reported-and-tested-by: Toralf Förster
> > CC:
>
> tested this patch against 3.10 - works fine too - thx.
>
> (th
On 07/11/2013 08:58 PM, Alan Stern wrote:
> This should be applied to the 3.10 stable kernel.
>
> Signed-off-by: Alan Stern
> Reported-and-tested-by: Toralf Förster
> CC:
tested this patch against 3.10 - works fine too - thx.
(this patch is a slightly modified variant of what you sent a week
The hub driver was recently changed to use "global" suspend for system
suspend transitions on non-SuperSpeed buses. This means that we don't
suspend devices individually by setting the suspend feature on the
upstream hub port; instead devices all go into suspend automatically
when the root hub sto
13 matches
Mail list logo
