On Wed, 25 Mar 2015, Alan Stern wrote:
> On Wed, 25 Mar 2015, Tomeu Vizoso wrote:
>
> > If a device isn't going to be fully-suspended because there isn't an
> > implementation of the suspend callback, there's no need to make sure
> > that its parent is going to be fully-suspended as well.
>
>
On Wed, 25 Mar 2015, Tomeu Vizoso wrote:
> If a device isn't going to be fully-suspended because there isn't an
> implementation of the suspend callback, there's no need to make sure
> that its parent is going to be fully-suspended as well.
What do you mean by "fully-suspended"?
What if the
If a device isn't going to be fully-suspended because there isn't an
implementation of the suspend callback, there's no need to make sure
that its parent is going to be fully-suspended as well.
Without this change, USB interface devices will always prevent the
proper USB device to stay in runtime
If a device isn't going to be fully-suspended because there isn't an
implementation of the suspend callback, there's no need to make sure
that its parent is going to be fully-suspended as well.
Without this change, USB interface devices will always prevent the
proper USB device to stay in runtime
On Wed, 25 Mar 2015, Tomeu Vizoso wrote:
If a device isn't going to be fully-suspended because there isn't an
implementation of the suspend callback, there's no need to make sure
that its parent is going to be fully-suspended as well.
What do you mean by fully-suspended?
What if the parent
On Wed, 25 Mar 2015, Alan Stern wrote:
On Wed, 25 Mar 2015, Tomeu Vizoso wrote:
If a device isn't going to be fully-suspended because there isn't an
implementation of the suspend callback, there's no need to make sure
that its parent is going to be fully-suspended as well.
What do you
6 matches
Mail list logo