Hi,
On Sat, Mar 2, 2013 at 9:23 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Sat, 2 Mar 2013, Vivek Gautam wrote:
By enabling runtime pm in this driver allows users of
xhci-plat to enter into runtime pm. This is not full
runtime pm support (AKA xhci-plat doesn't actually power
xhci has its own interrupt enabling routine, which will try to
use MSI-X/MSI if present. So the usb core shouldn't try to enable
legacy interrupts; on some machines the xhci legacy IRQ setting
is invalid.
Cc: Bjorn Helgaas bhelg...@google.com
Cc: Oliver Neukum oneu...@suse.de
Cc: Thomas Renninger
Use the newly introduced devm_ioremap_resource() instead of
devm_request_and_ioremap() which provides more consistent error handling.
devm_ioremap_resource() provides its own error messages; so all explicit
error messages can be removed from the failure code paths.
Signed-off-by: Sachin Kamat
Use the newly introduced devm_ioremap_resource() instead of
devm_request_and_ioremap() which provides more consistent error handling.
devm_ioremap_resource() provides its own error messages; so all explicit
error messages can be removed from the failure code paths.
Signed-off-by: Sachin Kamat
Use the newly introduced devm_ioremap_resource() instead of
devm_request_and_ioremap() which provides more consistent error handling.
devm_ioremap_resource() provides its own error messages; so all explicit
error messages can be removed from the failure code paths.
Signed-off-by: Sachin Kamat
2013/2/26 Alan Stern st...@rowland.harvard.edu:
Sarah (and anyone else who's interested):
A while ago I wrote about a hardware bug in my Intel ICH5 and ICH8 EHCI
controllers. You pointed out that these are rather old components, not
being used in current systems, which is quite true.
Now I
Hi,
On Wed, Feb 27, 2013 at 1:59 AM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Fri, Feb 22, 2013 at 07:09:39AM +, Yuan-Hsin Chen wrote:
From: Yuan-Hsin Chen yuan...@gmail.com
Due to fusb300 controller modification, stall clear procedure should be
modified consistantly. This patch also
On Mon, Mar 04, 2013 at 02:05:41PM +0530, Sachin Kamat wrote:
Use the newly introduced devm_ioremap_resource() instead of
devm_request_and_ioremap() which provides more consistent error handling.
devm_ioremap_resource() provides its own error messages; so all explicit
error messages can be
On Mon, Mar 04, 2013 at 02:05:42PM +0530, Sachin Kamat wrote:
Use the newly introduced devm_ioremap_resource() instead of
devm_request_and_ioremap() which provides more consistent error handling.
devm_ioremap_resource() provides its own error messages; so all explicit
error messages can be
On Mon, Mar 04, 2013 at 02:05:43PM +0530, Sachin Kamat wrote:
Use the newly introduced devm_ioremap_resource() instead of
devm_request_and_ioremap() which provides more consistent error handling.
devm_ioremap_resource() provides its own error messages; so all explicit
error messages can be
The three below functions:
smsc95xx_enter_suspend0()
smsc95xx_enter_suspend1()
smsc95xx_enter_suspend2()
return 0 in case of success, so they will cause smsc95xx_suspend()
to return 0 and suspend failure.
This patch is backported from the upstream commit:
From
On Mon, Mar 04, 2013 at 10:44:25AM +0800, Peter Chen wrote:
On Fri, Mar 01, 2013 at 03:42:23PM +0100, Michael Grzeschik wrote:
There is no need to call ep_queue unlocked inside the own driver. We
move its functionionality into an unlocked version.
This patch removes potential unlocked
Hi Greg,
On Wed, Feb 27, 2013 at 04:43:22PM +0200, Darius Augulis wrote:
Hi balbi,
actually no. I don't work with this hardware any more and don't have
free time to support it.
Please feel free to remove it if it breaks other things.
since nobody seems to care about imx_udc and it's
On Mon, Mar 04, 2013 at 09:22:04AM +0100, Hannes Reinecke wrote:
xhci has its own interrupt enabling routine, which will try to
use MSI-X/MSI if present. So the usb core shouldn't try to enable
legacy interrupts; on some machines the xhci legacy IRQ setting
is invalid.
Cc: Bjorn Helgaas
Hello Franko,
This patch causes a number of regressions for both the Huawei devices I
have available for testing. One of them is completely unusable in v3.8
(unable to switch to modem mode) unless the usb-storage driver is
disabled.
I realize that some devices are historically handled by the
Hi Greg,
Here's my first set of fixes for the v3.9-rc cycle. Nothing scary, all fixes
have been pending for a while now. I ran a few randconfig cycles with my
own seed, all looks good.
Let me know if you want any changes.
The following changes since commit
Use more preferable function name which implies using a pseudo-random
number generator.
Signed-off-by: Akinobu Mita akinobu.m...@gmail.com
Cc: linux-usb@vger.kernel.org
---
No change from v2
drivers/uwb/rsv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
Hello.
On 04-03-2013 12:22, Hannes Reinecke wrote:
xhci has its own interrupt enabling routine, which will try to
use MSI-X/MSI if present. So the usb core shouldn't try to enable
legacy interrupts; on some machines the xhci legacy IRQ setting
is invalid.
Cc: Bjorn Helgaas
On Wed, Feb 20, 2013 at 11:07:11PM -0500, Chao Xie wrote:
The PHY is seperated from usb controller.
The usb controller used in marvell pxa168/pxa910/mmp2 are same,
but PHY initialization may be different.
the usb controller can support udc/otg/ehci, and for each of
the mode, it need PHY to
On Wed, Feb 20, 2013 at 11:07:12PM -0500, Chao Xie wrote:
Originaly, udc driver will call the callbacks in platform data
for PHY initialization and shut down.
With PHY driver, it will call the APIs provided by PHY driver
for PHY initialization and shut down. It removes the callbacks
in
On Mon, 2013-03-04 at 14:19 +0100, Bjørn Mork wrote:
[...]
In-kernel mode switching was deprecated years ago with the
development of the more user friendly userspace alternatives. The
existing list of devices in usb-storage was only kept to prevent
breaking already working systems. The long
Hi,
On Thu, Feb 28, 2013 at 04:13:01PM +0800, Chen Gang wrote:
originally, when deleted the relative code, left some 'another'.
need delete 'another', too.
the relative patches are:
commit 96f8db6a77e3490608e5b5b3f57e7201f8c85496
Author: Felipe Balbi ba...@ti.com
Date:
On Thu, Feb 28, 2013 at 11:38:52AM +0100, Fabio Baltieri wrote:
Add transceiver notifier event handling to the ux500 driver to set vbus
on specific transceiver events.
Acked-by: Linus Walleij linus.wall...@linaro.org
Signed-off-by: Fabio Baltieri fabio.balti...@linaro.org
---
Hi,
On Fri, Mar 01, 2013 at 08:41:29AM +0200, Felipe Balbi wrote:
Moreover, SoCs having multiple dwc3 controllers will have multiple
PHYs, which eventually be added using usb_add_phy_dev(), and not
using usb_add_phy(). So each dwc3 controller won't be able to
get PHYs by
On Mon, 4 Mar 2013, Ming Lei wrote:
On Tue, Feb 26, 2013 at 4:54 AM, Alan Stern st...@rowland.harvard.edu wrote:
I'd be interested to hear the results of testing on a variety of
controllers. (This computer also has an NEC EHCI controller, and that
one does not have the bug.) Do the
On Mon, 4 Mar 2013, Bo Shen wrote:
Hi Alan,
On 02/26/2013 04:54 AM, Alan Stern wrote:
Sarah (and anyone else who's interested):
A while ago I wrote about a hardware bug in my Intel ICH5 and ICH8 EHCI
controllers. You pointed out that these are rather old components, not
being used
On Mon, 4 Mar 2013, Hannes Reinecke wrote:
xhci has its own interrupt enabling routine, which will try to
use MSI-X/MSI if present. So the usb core shouldn't try to enable
legacy interrupts; on some machines the xhci legacy IRQ setting
is invalid.
This version of the patch is much better
On Mon, 4 Mar 2013, Vivek Gautam wrote:
@@ -149,6 +150,8 @@ static int xhci_plat_probe(struct platform_device
*pdev)
if (ret)
goto put_usb3_hcd;
+ pm_runtime_enable(pdev-dev);
This is generally not a good idea. You shouldn't enable a device for
runtime
Hi,
On Sat, Mar 02, 2013 at 06:53:02PM +0530, Vivek Gautam wrote:
Adding APIs to handle runtime power management on PHY
devices. PHY consumers may need to wake-up/suspend PHYs
when they work across autosuspend.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
On Mon, 4 Mar 2013, Lan Tianyu wrote:
Test on the Sandybridge platform.
At the first time, I get following output. But after that, I was
hard to get any output. And test on the v3.8.
You have to unplug the flash drive after running the test each time.
By the way, be sure to apply Clemens
On Sun, 3 Mar 2013, Felipe Balbi wrote:
this is good point and, in fact, a doubt I have myself. How are we
supposed to check if device is suspended ? In case it _is_ suspended we
might not be able to read device's registers due to clocks possibly
being gated.
That's really a
On Monday, March 04, 2013 10:26:40 AM Alan Stern wrote:
On Mon, 4 Mar 2013, Hannes Reinecke wrote:
xhci has its own interrupt enabling routine, which will try to
use MSI-X/MSI if present. So the usb core shouldn't try to enable
legacy interrupts; on some machines the xhci legacy IRQ setting
From: Hannes Reinecke h...@suse.de
xhci has its own interrupt enabling routine, which will try to
use MSI-X/MSI if present. So the usb core shouldn't try to enable
legacy interrupts; on some machines the xhci legacy IRQ setting
is invalid.
v3: Be careful to not break XHCI_BROKEN_MSI workaround
Ben Hutchings b...@decadent.org.uk writes:
On Mon, 2013-03-04 at 14:19 +0100, Bjørn Mork wrote:
[...]
In-kernel mode switching was deprecated years ago with the
development of the more user friendly userspace alternatives. The
existing list of devices in usb-storage was only kept to prevent
On 03/04/2013 12:55 AM, Venu Byravarasu wrote:
Stephen Warren wrote at Thursday, February 28, 2013 11:47 PM:
On 02/27/2013 11:36 PM, Venu Byravarasu wrote:
To clear any configurations made by U-Boot on Tegra USB controller,
reset it before init in probe.
diff --git
Frankly, I consider it appropriate.
The question is not one of reminding me of what I said earlier
it's one of pointing people in the right direction. Frankly, some of
the fault for this patch lies with Greg and myself for letting it
through. I had just assumed that the Huawei guys had
Hello.
On 03/04/2013 07:14 PM, Thomas Renninger wrote:
From: Hannes Reineckeh...@suse.de
xhci has its own interrupt enabling routine, which will try to
use MSI-X/MSI if present. So the usb core shouldn't try to enable
legacy interrupts; on some machines the xhci legacy IRQ setting
is invalid.
On Mon, 4 Mar 2013, Sergei Shtylyov wrote:
@@ -371,6 +371,7 @@ static int xhci_try_enable_msi(struct usb_hcd *hcd)
return -EINVAL;
}
+ legacy_irq:
Labels shouldn't be indented by a space (unless the existing coding
style has them indented already, of
On Mon, 4 Mar 2013, Stephen Warren wrote:
On 03/04/2013 12:55 AM, Venu Byravarasu wrote:
Stephen Warren wrote at Thursday, February 28, 2013 11:47 PM:
On 02/27/2013 11:36 PM, Venu Byravarasu wrote:
To clear any configurations made by U-Boot on Tegra USB controller,
reset it before init
Am 25.02.2013 21:54, schrieb Alan Stern:
Sarah (and anyone else who's interested):
A while ago I wrote about a hardware bug in my Intel ICH5 and ICH8 EHCI
controllers. You pointed out that these are rather old components, not
being used in current systems, which is quite true.
Now I have
On Mon, 4 Mar 2013, [ISO-8859-1] Frank Sch�fer wrote:
Here is the result of your test procedure (fix applied, running kernel
3.9-rc1) for the following device:
00:02.1 USB controller [0c03]: NVIDIA Corporation MCP61 USB 2.0
Controller [10de:03f2] (rev a2) (prog-if 20 [EHCI])
From: Ming Lei ming@canonical.com
Date: Mon, 4 Mar 2013 18:07:13 +0800
The three below functions:
smsc95xx_enter_suspend0()
smsc95xx_enter_suspend1()
smsc95xx_enter_suspend2()
return 0 in case of success, so they will cause smsc95xx_suspend()
to return 0
Matthew Dharm mdharm-...@one-eyed-alien.net writes:
Frankly, I consider it appropriate.
OK, I'll try to cook something up.
The question is not one of reminding me of what I said earlier
it's one of pointing people in the right direction. Frankly, some of
the fault for this patch lies
Hi Greg,
Here is the latest version of the DWC2 patch set. This version includes
changes suggested by Felipe in his last review, plus a couple of changes
requested by Alan Stern.
Please consider applying these to usb-next. Felipe thought these should
go in through your tree, since they don't
Add a usb_otg_state_string() routine to print the OTG state for
debugging
Signed-off-by: Paul Zimmerman pa...@synopsys.com
Acked-by: Felipe Balbi ba...@ti.com
---
drivers/usb/usb-common.c | 26 ++
include/linux/usb/phy.h | 8
2 files changed, 34 insertions(+)
This file contains code to support the HCD descriptor DMA mode of
the controller
Signed-off-by: Paul Zimmerman pa...@synopsys.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
drivers/usb/dwc2/hcd_ddma.c | 1183 +++
1 file changed, 1183 insertions(+)
create
This file contains the PCI bus interface glue for the DWC2 driver
Signed-off-by: Paul Zimmerman pa...@synopsys.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
drivers/usb/dwc2/pci.c | 198 +
1 file changed, 198 insertions(+)
create mode 100644
Add the DWC2 Kconfig and Makefile, and modify the USB Kconfig and
Makefile to include them
Signed-off-by: Paul Zimmerman pa...@synopsys.com
Acked-by: Felipe Balbi ba...@ti.com
---
drivers/usb/Kconfig | 2 ++
drivers/usb/Makefile | 2 ++
drivers/usb/dwc2/Kconfig | 41
Add myself as maintainer of the DWC2 driver
Signed-off-by: Paul Zimmerman pa...@synopsys.com
---
MAINTAINERS | 6 ++
1 file changed, 6 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index e95b1e9..27874f0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2470,6 +2470,12 @@ M:
Fengguang Wu run into a kernel ops after he complied dummy_hcd and g_cdc
into the kernel. The problem was that u_serial was used by g_cdc before
u_serial was initialized. In the module case eveything is initialized in
the correct order but if we compile it into the kernel we rely on
Makefile order
Signed-off-by: Bjørn Mork bj...@mork.no
---
So, is something like this good enough?
Bjørn
drivers/usb/storage/unusual_devs.h |8
1 file changed, 8 insertions(+)
diff --git a/drivers/usb/storage/unusual_devs.h
b/drivers/usb/storage/unusual_devs.h
index d305a5a..1e03a45 100644
---
Hello.
On 03/05/2013 12:57 AM, Bjørn Mork wrote:
Signed-off-by: Bjørn Mork bj...@mork.no
---
So, is something like this good enough?
Bjørn
drivers/usb/storage/unusual_devs.h |8
1 file changed, 8 insertions(+)
diff --git a/drivers/usb/storage/unusual_devs.h
On Mon, Mar 04 2013, Sebastian Andrzej Siewior wrote:
Fengguang Wu run into a kernel ops after he complied dummy_hcd and g_cdc
into the kernel. The problem was that u_serial was used by g_cdc before
u_serial was initialized. In the module case eveything is initialized in
the correct order but
On Mon, Mar 04, 2013 at 10:57:22PM +0100, Bjørn Mork wrote:
Signed-off-by: Bjørn Mork bj...@mork.no
---
So, is something like this good enough?
Bjørn
[...]
I think this comment is good, but then it's not my driver.
Ben.
--
Ben Hutchings
We get into the habit of living before acquiring
Fix trivial kernel-doc warnings:
Warning(include/linux/usb.h:574): No description found for parameter
'usb3_lpm_enabled'
Warning(include/linux/usb.h:574): Excess struct/union/enum/typedef member
'usb_classdev' description in 'usb_device'
Warning(include/linux/usb.h:574): Excess
A few trivial fixes for composite driver.
Fixes:
Warning(include/linux/usb/composite.h:165): No description found for parameter
'fs_descriptors'
Warning(include/linux/usb/composite.h:165): Excess struct/union/enum/typedef
member 'descriptors' description in 'usb_function'
I'm happy with it, modulo Sergi's grammer comment.
ACKed-by: Matthew Dharm mdharm-...@one-eyed-alien.net
Matt
On Mon, Mar 4, 2013 at 1:57 PM, Bjørn Mork bj...@mork.no wrote:
Signed-off-by: Bjørn Mork bj...@mork.no
---
So, is something like this good enough?
Bjørn
Am 04.03.2013 20:22, schrieb Bjørn Mork:
Matthew Dharm mdharm-...@one-eyed-alien.net writes:
The question is not one of reminding me of what I said earlier
it's one of pointing people in the right direction. Frankly, some of
the fault for this patch lies with Greg and myself for letting it
On Mon, Mar 04, 2013 at 12:21:43PM -0800, Paul Zimmerman wrote:
Hi Greg,
Here is the latest version of the DWC2 patch set. This version includes
changes suggested by Felipe in his last review, plus a couple of changes
requested by Alan Stern.
Please consider applying these to usb-next.
On Mon, Mar 04, 2013 at 09:55:44AM -0700, Stephen Warren wrote:
On 03/04/2013 12:55 AM, Venu Byravarasu wrote:
Stephen Warren wrote at Thursday, February 28, 2013 11:47 PM:
On 02/27/2013 11:36 PM, Venu Byravarasu wrote:
To clear any configurations made by U-Boot on Tegra USB controller,
On Mon, Mar 04, 2013 at 02:24:20PM +0200, Felipe Balbi wrote:
Hi Greg,
Here's my first set of fixes for the v3.9-rc cycle. Nothing scary, all fixes
have been pending for a while now. I ran a few randconfig cycles with my
own seed, all looks good.
Let me know if you want any changes.
于 2013年03月02日 03:47, Laurent Pinchart 写道:
I've taken the patch in my tree.
I've just sent a consolidated series of most pending UVC gadget patches to
the
list, and I will send you a pull request as soon as I receive a Tested-by.
thanks
--
Chen Gang
Asianux Corporation
--
To
于 2013年03月04日 22:35, Felipe Balbi 写道:
this is the wrong fix, I believe. Looks like when I wrote the commits
you mention, I deleted more code then I should. Looks like the real fix
would be to add back:
/* report disconnect; the driver is already quiesced */
if (driver) {
On Mon, Mar 4, 2013 at 10:21 PM, Felipe Balbi ba...@ti.com wrote:
On Wed, Feb 20, 2013 at 11:07:11PM -0500, Chao Xie wrote:
The PHY is seperated from usb controller.
The usb controller used in marvell pxa168/pxa910/mmp2 are same,
but PHY initialization may be different.
the usb controller can
On Mon, Mar 4, 2013 at 10:24 PM, Felipe Balbi ba...@ti.com wrote:
On Wed, Feb 20, 2013 at 11:07:12PM -0500, Chao Xie wrote:
Originaly, udc driver will call the callbacks in platform data
for PHY initialization and shut down.
With PHY driver, it will call the APIs provided by PHY driver
for
-Original Message-
From: Bjørn Mork [mailto:bj...@mork.no]
Sent: Monday, March 04, 2013 9:19 PM
To: linux-usb@vger.kernel.org
Cc: linux-ker...@vger.kernel.org; Fangxiaozhi (Franko); Xueguiying (Zihan);
Linlei (Lei Lin); Greg KH; Yili (Neil); Wangyuhua (Roger, Credit); Huqiao (C);
Dear Mork:
Thank you very much for your test.
-Original Message-
From: Bjørn Mork [mailto:bj...@mork.no]
Sent: Monday, March 04, 2013 7:41 PM
To: Fangxiaozhi (Franko)
Cc: linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org; Xueguiying
(Zihan); Linlei (Lei Lin);
于 2013年03月04日 01:35, Laurent Pinchart 写道:
On Sunday 03 March 2013 01:23:46 Felipe Balbi wrote:
On Fri, Mar 01, 2013 at 08:47:34PM +0100, Laurent Pinchart wrote:
On Wednesday 27 February 2013 10:26:23 Felipe Balbi wrote:
On Sat, Feb 02, 2013 at 03:48:54PM +0800, Chen Gang wrote:
Hi Alan,
On 3/4/2013 23:16, Alan Stern wrote:
On Mon, 4 Mar 2013, Bo Shen wrote:
Hi Alan,
On 02/26/2013 04:54 AM, Alan Stern wrote:
Sarah (and anyone else who's interested):
A while ago I wrote about a hardware bug in my Intel ICH5 and ICH8 EHCI
controllers. You pointed out that these are
Hi,
This patch adds comments on interface driver suspend callback
to emphasize that the failure return value is ignored by
USB core in system sleep context, so do not try to recover
device for this case, otherwise the URB traffic scheduled
in recovery of failure path may cross system sleep, and
This patch adds comments on interface driver suspend callback
to emphasize that the failure return value is ignored by
USB core in system sleep context, so do not try to recover
device for this case.
Signed-off-by: Ming Lei ming@canonical.com
---
include/linux/usb.h |5 -
1 file
This patch kills traffic even though type-suspend returns
failure inside usb_serial_suspend from system sleep context
because USB core ignores the failiure and lets system sleep
go ahread, so the serial URB traffic need to be killed
in this case.
Cc: Johan Hovold jhov...@gmail.com
Signed-off-by:
If suspend callback fails in system sleep context, usb core will
ignore the failure and let the system sleep go ahead further, so this
patch doesn't recover device under this situation.
Cc: Jiri Kosina jkos...@suse.cz
Signed-off-by: Ming Lei ming@canonical.com
---
If suspend callback fails in system sleep context, usb core will
ignore the failure and let system sleep go ahead further, so
this patch doesn't recover device under this situation.
Cc: Bjørn Mork bj...@mork.no
Signed-off-by: Ming Lei ming@canonical.com
---
drivers/net/usb/cdc_mbim.c |2
If suspend callback fails in system sleep context, usb core will
ignore the failure and let system sleep go ahead further, so
this patch doesn't recover device under this situation.
Cc: Steve Glendinning steve.glendinn...@shawell.net
Signed-off-by: Ming Lei ming@canonical.com
---
If suspend callback fails in system sleep context, usb core will
ignore the failure and let system sleep go ahead further, so
this patch doesn't recover device under this situation.
Cc: Steve Glendinning steve.glendinn...@shawell.net
Signed-off-by: Ming Lei ming@canonical.com
---
If suspend callback fails in system sleep context, usb core will
ignore the failure and let system sleep go ahead further, so
this patch doesn't recover device under this situation.
Cc: Bjørn Mork bj...@mork.no
Signed-off-by: Ming Lei ming@canonical.com
---
drivers/net/usb/qmi_wwan.c |2
module_platform_driver_probe() eliminates the boilerplate and simplifies
the code.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
Cc: Li Yang le...@freescale.com
---
drivers/usb/gadget/fsl_udc_core.c | 16 +---
1 files changed, 1 insertions(+), 15 deletions(-)
diff --git
On Tue, Mar 5, 2013 at 12:01 PM, Ming Lei ming@canonical.com wrote:
Hi,
This patch adds comments on interface driver suspend callback
to emphasize that the failure return value is ignored by
USB core in system sleep context, so do not try to recover
device for this case, otherwise the
Ming Lei ming@canonical.com writes:
Hi,
This patch adds comments on interface driver suspend callback
to emphasize that the failure return value is ignored by
USB core in system sleep context, so do not try to recover
device for this case, otherwise the URB traffic scheduled
in
Ming Lei ming@canonical.com writes:
If suspend callback fails in system sleep context, usb core will
ignore the failure and let system sleep go ahead further, so
this patch doesn't recover device under this situation.
Cc: Bjørn Mork bj...@mork.no
Signed-off-by: Ming Lei
Ming Lei ming@canonical.com writes:
If suspend callback fails in system sleep context, usb core will
ignore the failure and let system sleep go ahead further, so
this patch doesn't recover device under this situation.
Cc: Bjørn Mork bj...@mork.no
Signed-off-by: Ming Lei
82 matches
Mail list logo
