Use usbnet_link_change to handle link change centrally.
Signed-off-by: Ming Lei ming@canonical.com
---
drivers/net/usb/ax88179_178a.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/net/usb/ax88179_178a.c b/drivers/net/usb/ax88179_178a.c
index
Use usbnet_link_change to handle link change centrally.
Signed-off-by: Ming Lei ming@canonical.com
---
drivers/net/usb/cdc_ether.c |5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
index 57136dc..e965806
Use usbnet_link_change to handle link change centrally.
Signed-off-by: Ming Lei ming@canonical.com
---
drivers/net/usb/sierra_net.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/usb/sierra_net.c b/drivers/net/usb/sierra_net.c
index 79ab243..a923d61
Use usbnet_link_change to handle link change centrally.
Signed-off-by: Ming Lei ming@canonical.com
---
drivers/net/usb/usbnet.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index 40e4237..34e4252 100644
Use usbnet_link_change to handle link change centrally.
Cc: Peter Korsgaard jac...@sunsite.dk
Signed-off-by: Ming Lei ming@canonical.com
---
drivers/net/usb/dm9601.c |7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/net/usb/dm9601.c b/drivers/net/usb/dm9601
bytes (839 MB) copied, 32.5492 s, 25.8 MB/s
5, 838860800 bytes (839 MB) copied, 31.6178 s, 26.5 MB/s
average: 26.1MB/s
Signed-off-by: Ming Lei ming@canonical.com
---
drivers/net/usb/usbnet.c | 30 ++
include/linux/usb/usbnet.h |1 +
2 files changed, 31
On Thu, Apr 11, 2013 at 10:40 PM, Ming Lei ming@canonical.com wrote:
The link change is detected via the interrupt pipe, and bulk
pipes are responsible for transfering packets, so it is reasonable
to stop bulk transfer after link is reported as off.
Two adavantages may be obtained
On Thu, Apr 11, 2013 at 11:18 PM, Jussi Kivilinna
jussi.kivili...@iki.fi wrote:
On 11.04.2013 17:40, Ming Lei wrote:
Hi,
This patch set introduces usbnet_link_change() API and applies
it on all usbnet drivers, then handle the link change centrally
to stop bulk transfer when link becomes off
can apply allocation
of GFP_NOIO automatically in resume path now, and you can always
use GFP_KERNEL safely. Considered that it is a API, please don't
introduce it.
After removing it, you can add
Acked-by: Ming Lei ming@canonical.com
+{
+ int ret = 0
usec
Looks that just means very slow read data from coherent buffer, or
bad memcpy?
Also you might need to check if you use gp_timer as default
clocksource, otherwise the default 32K timer only gives you a
~30us accuracy.
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line
to maximum of 3318
microsecond. Looks like callback handler doing
If you are playing ARM and I remember correctly, it is quite slow to read
coherent memory from CPU, but writing is OK because of store buffer.
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line unsubscribe linux-usb
: stable sta...@vger.kernel.org
Signed-off-by: Ming Lei tom.leim...@gmail.com
---
Cc stable since the previous patchset is marked as stable.
drivers/usb/serial/usb-serial.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/serial/usb-serial.c b/drivers/usb/serial/usb-serial.c
index
doesn't have the problem observed on my Pandaboard A1,
but I only tested booting from MMC, not from NFS.
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
on Pandaboard A1 frequently, looks not
see the failure problem before. Maybe the problem is config dependent.
If you may share your config file, I'd like to do the test too.
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord
.
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Mar 14, 2013 at 6:19 PM, Oliver Neukum oneu...@suse.de wrote:
On Thursday 14 March 2013 18:07:29 Ming Lei wrote:
But then it makes no sense and you'd be better of with a waitqueue
instead of a completion.
Maybe we can do it in another patch.
Part of the locking changes would need
On Thu, Mar 14, 2013 at 7:10 PM, Johan Hovold jhov...@gmail.com wrote:
On Fri, Mar 08, 2013 at 12:15:19AM +0800, Ming Lei wrote:
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
|6 +-
drivers/usb/core/driver.c | 11 ---
drivers/usb/serial/usb-serial.c |5 +
include/linux/usb.h |7 ++-
8 files changed, 44 insertions(+), 15 deletions(-)
Thanks
--
Ming Lei
--
To unsubscribe from this list: send the line unsubscribe linux-usb
for usb_suspend_both() is updated with the
fact.
Acked-by: Alan Stern st...@rowland.harvard.edu
Signed-off-by: Ming Lei ming@canonical.com
---
drivers/usb/core/driver.c | 11 ---
include/linux/usb.h |7 ++-
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers
If suspend callback fails in system sleep context, usb core will
ignore the failure and let system sleep go ahead further, so
this patch comments on the case and requires that serial-type-suspend()
MUST return 0 in system sleep context.
Cc: Johan Hovold jhov...@gmail.com
Signed-off-by: Ming Lei
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, otherwise
may cause resume() confused.
Acked-by: Jiri Kosina jkos...@suse.cz
Signed-off-by: Ming Lei ming
...@davemloft.net
Acked-by: Bjørn Mork bj...@mork.no
Signed-off-by: Ming Lei ming@canonical.com
---
drivers/net/usb/cdc_mbim.c |5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/net/usb/cdc_mbim.c b/drivers/net/usb/cdc_mbim.c
index 248d2dc..406a34d 100644
--- a/drivers/net/usb
...@davemloft.net
Acked-by: Bjørn Mork bj...@mork.no
Signed-off-by: Ming Lei ming@canonical.com
---
drivers/net/usb/qmi_wwan.c |5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 968d5d5..bdceb74 100644
--- a/drivers/net/usb
...@shawell.net
Signed-off-by: Ming Lei ming@canonical.com
---
drivers/net/usb/smsc95xx.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c
index e6d2dea..3f38ba8 100644
--- a/drivers/net/usb/smsc95xx.c
+++ b
...@shawell.net
Signed-off-by: Ming Lei ming@canonical.com
---
drivers/net/usb/smsc75xx.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/smsc75xx.c b/drivers/net/usb/smsc75xx.c
index 9abe517..21b607a 100644
--- a/drivers/net/usb/smsc75xx.c
+++ b
.
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Mar 13, 2013 at 10:55 PM, Oliver Neukum oneu...@suse.de wrote:
But it will be run when the next read() call is made. The question is what
happens
When next read() is called, looks it won't be reached if
'ongoing_read' is set, and
it needn't run without ongoing URBs.
Thanks,
--
Ming
On Wed, Mar 13, 2013 at 11:15 PM, Oliver Neukum oneu...@suse.de wrote:
On Wednesday 13 March 2013 23:02:32 Ming Lei wrote:
On Wed, Mar 13, 2013 at 10:55 PM, Oliver Neukum oneu...@suse.de wrote:
But it will be run when the next read() call is made. The question is what
happens
When next
wondering why the device lock is needed for usbdev_do_ioctl()? Looks
device lock isn't required for USB transfer of kernel driver.
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info
device lock in submitting
URB path? Device lock isn't required before submitting URBs
in kernel driver.
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
On Tue, Mar 12, 2013 at 12:08 AM, Alan Stern st...@rowland.harvard.edu wrote:
On Mon, 11 Mar 2013, Ming Lei wrote:
On Mon, Mar 11, 2013 at 11:32 PM, Alan Stern st...@rowland.harvard.edu
wrote:
Of course you have to lock the device before changing its driver. What
would happen if two
for usb_suspend_both() is updated with the
fact.
Signed-off-by: Ming Lei ming@canonical.com
---
drivers/usb/core/driver.c | 11 ---
include/linux/usb.h |7 ++-
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/core/driver.c b/drivers/usb/core/driver.c
/usb.h |7 ++-
8 files changed, 41 insertions(+), 16 deletions(-)
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
-by: Ming Lei ming@canonical.com
---
drivers/usb/serial/usb-serial.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/serial/usb-serial.c b/drivers/usb/serial/usb-serial.c
index a19ed74..9d0b9c8 100644
--- a/drivers/usb/serial/usb-serial.c
+++ b/drivers/usb/serial
/usb-serial.c |3 ++-
include/linux/usb.h |7 ++-
8 files changed, 41 insertions(+), 16 deletions(-)
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
for usb_suspend_both() is updated with the
fact.
Signed-off-by: Ming Lei ming@canonical.com
---
drivers/usb/core/driver.c | 11 ---
include/linux/usb.h |7 ++-
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/core/driver.c b/drivers/usb/core/driver.c
-by: Ming Lei ming@canonical.com
---
drivers/usb/serial/usb-serial.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/serial/usb-serial.c b/drivers/usb/serial/usb-serial.c
index a19ed74..9d0b9c8 100644
--- a/drivers/usb/serial/usb-serial.c
+++ b/drivers/usb/serial
-off-by: Ming Lei ming@canonical.com
---
drivers/net/usb/cdc_mbim.c |5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/net/usb/cdc_mbim.c b/drivers/net/usb/cdc_mbim.c
index 248d2dc..406a34d 100644
--- a/drivers/net/usb/cdc_mbim.c
+++ b/drivers/net/usb/cdc_mbim.c
@@ -332,6
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.
Also add comments on the case.
Cc: Steve Glendinning steve.glendinn...@shawell.net
Signed-off-by: Ming Lei ming
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.
Also add comments on this case.
Cc: Steve Glendinning steve.glendinn...@shawell.net
Signed-off-by: Ming Lei ming
and several usbnet drivers
which may recover device in suspend failure path of system sleep.
v1:
- fix compile failure
- add comments about handling suspend failure in resume()
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body
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 and let resume/reset_resume callback
handle the suspend failure if needed.
Signed-off-by: Ming Lei
-by: Ming Lei ming@canonical.com
---
drivers/usb/serial/usb-serial.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/serial/usb-serial.c b/drivers/usb/serial/usb-serial.c
index a19ed74..9d0b9c8 100644
--- a/drivers/usb/serial/usb-serial.c
+++ b/drivers/usb/serial
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, otherwise
may cause resume() confused.
Cc: Jiri Kosina jkos...@suse.cz
Signed-off-by: Ming Lei ming
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
---
drivers/net
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
---
drivers/net
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
On Wed, Mar 6, 2013 at 11:25 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Wed, 6 Mar 2013, Ming Lei wrote:
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
On Tue, Mar 5, 2013 at 3:03 PM, Bjørn Mork bj...@mork.no wrote:
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
On Tue, Mar 5, 2013 at 3:09 PM, Bjørn Mork bj...@mork.no wrote:
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
On Tue, Mar 5, 2013 at 3:09 PM, Bjørn Mork bj...@mork.no wrote:
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
.
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Mar 5, 2013 at 12:01 PM, Ming Lei ming@canonical.com wrote:
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
On Tue, Mar 5, 2013 at 9:28 PM, Oliver Neukum oneu...@suse.de wrote:
On Tuesday 05 March 2013 21:08:09 Ming Lei wrote:
On Tue, Mar 5, 2013 at 8:50 PM, Oliver Neukum oneu...@suse.de wrote:
In other words, if we don't handle errors, there must be no errors,
otherwise it doesn't matter what we
On Tue, Mar 5, 2013 at 9:46 PM, Bjørn Mork bj...@mork.no wrote:
Ming Lei ming@canonical.com writes:
On Tue, Mar 5, 2013 at 3:09 PM, Bjørn Mork bj...@mork.no wrote:
Ming Lei ming@canonical.com writes:
If suspend callback fails in system sleep context, usb core will
ignore the failure
On Tue, Mar 5, 2013 at 11:03 PM, Bjørn Mork bj...@mork.no wrote:
Ming Lei ming@canonical.com writes:
On Tue, Mar 5, 2013 at 9:46 PM, Bjørn Mork bj...@mork.no wrote:
Now, after inspecting wdm_suspend() which hides behind
info-subdriver-suspend(), I see that this is a completely theoretical
On Wed, Mar 6, 2013 at 12:08 AM, Bjørn Mork bj...@mork.no wrote:
Ming Lei ming@canonical.com writes:
I am starting to wonder why the USB core has combined system suspend and
runtime suspend if we are going to end up with every driver testing
PMSG_IS_AUTO(message) and selecting
On Wed, Mar 6, 2013 at 10:51 AM, Ming Lei ming@canonical.com wrote:
On Wed, Mar 6, 2013 at 12:08 AM, Bjørn Mork bj...@mork.no wrote:
Ming Lei ming@canonical.com writes:
I am starting to wonder why the USB core has combined system suspend and
runtime suspend if we are going to end up
7643721471117d5f62ca36f328d3dc8d84af4402 Mon Sep 17 00:00:00 2001
Subject: [PATCH] usbnet: smsc95xx: fix suspend failure
Cc: sta...@vger.kernel.org
Cc: Steve Glendinning steve.glendinn...@shawell.net
Signed-off-by: Ming Lei ming@canonical.com
---
drivers/net/usb/smsc95xx.c |6
, and may
cause problems.
Also fixes the USB serial, HID and several usbnet drivers
which may recover device in suspend failure path of system sleep.
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More
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
-by: Ming Lei ming@canonical.com
---
drivers/usb/serial/usb-serial.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/serial/usb-serial.c b/drivers/usb/serial/usb-serial.c
index a19ed74..04ad3d5 100644
--- a/drivers/usb/serial/usb-serial.c
+++ b/drivers/usb/serial
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
---
drivers/hid/usbhid/hid
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
---
drivers/net
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
---
drivers/net
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
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
pass the test? What about other vendors?
No the 'EHCI hardware bug detected' error are observed on EHCI
of OMAP4 pandaboard.
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info
Hi,
The 1st two patches fix smsc95xx_suspend, and the 1st one should
be backported to 3.8.
The last one is to rename the misleading FEATURE_AUTOSUSPEND.
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord
handling
in suspend failure case).
Cc: sta...@vger.kernel.org[3.8]
Cc: Steve Glendinning steve.glendinn...@shawell.net
Signed-off-by: Ming Lei ming@canonical.com
---
drivers/net/usb/smsc95xx.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git
...@shawell.net
Signed-off-by: Ming Lei ming@canonical.com
---
drivers/net/usb/smsc95xx.c | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c
index b2721bc..7fa9622 100644
--- a/drivers/net/usb/smsc95xx.c
-by: Ming Lei ming@canonical.com
---
drivers/net/usb/smsc95xx.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c
index 7fa9622..e6d2dea 100644
--- a/drivers/net/usb/smsc95xx.c
+++ b/drivers/net/usb/smsc95xx.c
On Fri, Feb 1, 2013 at 7:43 AM, Andrew Morton a...@linux-foundation.org wrote:
On Wed, 30 Jan 2013 19:53:22 +0800
Ming Lei ming@canonical.com wrote:
The allocation failure is caused by the big sizeof(struct parsed_partitions),
which is 64K in my 32bit box,
Geeze.
We could fix
;
char *pp_buf;
};
+extern void release_partitions(struct parsed_partitions *state);
+
struct parsed_partitions *
check_partition(struct gendisk *, struct block_device *);
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message
On Fri, Jan 25, 2013 at 11:23 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Fri, 25 Jan 2013, Ming Lei wrote:
Good. Can I add your Tested-by: when I submit it?
Sure, please feel free to add the below:
Tested-by: Ming Lei ming@canonical.com
Thanks,
--
Ming Lei
inline bool usb_hcd_get_rh_ports_resuming(struct usb_device
*rhdev) {return false;}
#endif /* CONFIG_USB_SUSPEND */
/*-*/
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body
one
hub device into your host controller, but you will find that the port change
event is retrieved and no 'suspend failed because a port is resuming' shows
in the dmesg log.
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord
or others?
continues for more than 10 seconds! If the delay were set to 30 ms,
the amount of activity would be greatly reduced.
IMO, if it is a normal use case on USB bus or device, we need to consider
adjusting the default delay for hub, but it is still not sure, :-)
Thanks,
--
Ming Lei
pm_runtime_get_noresume. Can you think of anything better?
pm_runtime_get_noresume should be better than adjusting autosuspend
delay, but the 'suspend failed' message can't be avoided. Or could we
schedule a delayed work to handle hub_activate(HUB_RESUME) for
the case?
Thanks,
--
Ming Lei
--
To unsubscribe
autosuspend.
*/
Alan mentioned that we may add one pm_runtime_get_noresume()
to avoid root-hub auto-suspend when it is sending ports resuming
signal from remote-wakeup.
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message
inline bool usb_hcd_get_rh_ports_resuming(struct usb_device
*rhdev) {return false;}
#endif /* CONFIG_USB_SUSPEND */
/*-*/
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body
for single target
device.
Signed-off-by: Ming Lei ming@canonical.com
---
drivers/usb/storage/usb.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/storage/usb.c b/drivers/usb/storage/usb.c
index 31b3e1a..07b3e54 100644
--- a/drivers/usb/storage/usb.c
+++ b/drivers/usb
pet...@users.sourceforge.net
Signed-off-by: Ming Lei ming@canonical.com
---
drivers/net/usb/pegasus.c |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/pegasus.c b/drivers/net/usb/pegasus.c
index a0b5807..44f46fd 100644
--- a/drivers/net/usb/pegasus.c
On Sun, Jan 20, 2013 at 4:22 AM, Matthew Dharm
mdharm-...@one-eyed-alien.net wrote:
Let me try this again...
It looks fine to me.
Acked-by: Matthew Dharm mdharm-...@one-eyed-alien.net
Sorry for forgetting Cc Matt, thanks Alan and Matt.
Thanks,
--
Ming Lei
--
To unsubscribe from this list
, Rafael, Greg and other guys who
reviewed and gave suggestions on this patch set.
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
to see
it applied.
I think it is the right thing, at least many network drivers do that, such as
smsc usbnet drivers and many of PCI ethernet drivers.
So I will prepare one formal version for merge.
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line unsubscribe linux-usb
On Thu, Jan 17, 2013 at 7:37 AM, Andrew Morton
a...@linux-foundation.org wrote:
On Sat, 5 Jan 2013 10:25:38 +0800
Ming Lei ming@canonical.com wrote:
This patchset try to solve one deadlock problem which might be caused
by memory allocation with block I/O during runtime PM and block
that sync
for all async things inside loading module?
So looks only sd.c and floppy.c are to be synchronized suppose
some sync interfaces are introduced, doesn't it?
Thanks
--
Ming Lei
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord
of 'sd_mod'.
Tested-by: Ming Lei ming@canonical.com
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
be triggered too, so it should be one same problem.
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Jan 15, 2013 at 1:23 AM, Dan Williams d...@redhat.com wrote:
On Fri, 2013-01-11 at 11:06 +0800, Ming Lei wrote:
I am curious who are interested in the 'custom Restart indication'
information after the interface is closed.
It's actually before the interface is even opened. It's really
On Tue, Jan 15, 2013 at 1:30 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Sun, Jan 13, 2013 at 11:15 PM, Ming Lei ming@canonical.com wrote:
The deadlock problem is caused by calling request_module() inside
async function of do_scan_async(), and it was introduced by Linus's
On Tue, Jan 15, 2013 at 9:53 AM, Ming Lei ming@canonical.com wrote:
I will try to figure out one patch to address the scsi block async probe
issue first, and see if it can fix the problem by moving add_disk()
into sd_probe()
and calling async_synchronize_full_domain(scsi_sd_probe_domain
] (sys_init_module+0x104/0x110)
[ 271.190979] [c0085944] (sys_init_module+0x104/0x110) from
[c000dfe0] (ret_fast_syscall+0x0/0x48)
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info
-DEV is the hub device's name.
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Cc netdev and usb lists.
On Fri, Jan 11, 2013 at 9:17 AM, fre...@asix.com.tw wrote:
From: Freddy Xin fre...@asix.com.tw
This patch adds a driver for ASIX's AX88179 family of USB 3.0/2.0
to gigabit ethernet adapters. It's based on the AX88xxx driver but
the usb commands used to access
status
even it is closed, but looks no much actual usage, so guys opt to
submit the interrupt URB only after it is opened.
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
URBs
that are successfully submitted. I'm not sure what useful information I could
get from the trace.
It might be useful to post the relevant 'dmesg' and the usbmon together.
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message
401 - 500 of 754 matches
Mail list logo
