[PATCH] usb: chipidea: imx: Use dev_name() for ci_hdrc name to distinguish USBs
Signed-off-by: Alexander Shiyan shc_w...@mail.ru
---
drivers/usb/chipidea/ci_hdrc_imx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c
b/drivers/usb/chipidea/ci_hdrc_imx.c
index c00f772..2e58f8d 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.c
+++ b/drivers/usb/chipidea/ci_hdrc_imx.c
@@ -96,7 +96,7 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
{
struct ci_hdrc_imx_data *data;
struct ci_hdrc_platform_data pdata = {
- .name = ci_hdrc_imx,
+ .name = dev_name(pdev-dev),
.capoffset = DEF_CAPOFFSET,
.flags = CI_HDRC_REQUIRE_TRANSCEIVER |
CI_HDRC_DISABLE_STREAMING,
--
1.8.3.2
--
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
[PATCH v2 5/9] usb: don't use PREPARE_DELAYED_WORK
Hello,
If this is actually safe, let's do it from the get-go.
Thanks!
--- 8 ---
PREPARE_[DELAYED_]WORK() are being phased out. They have few users
and a nasty surprise in terms of reentrancy guarantee as workqueue
considers work items to be different if they don't have the same work
function.
usb_hub-init_work is multiplexed with multiple work functions;
however, the work item is never queued while in-flight, so we can
simply use INIT_DELAYED_WORK() before each queueing.
It would probably be best to route this with other related updates
through the workqueue tree.
Lightly tested.
v2: Greg and Alan confirm that the work item is never queued while
in-flight. Simply use INIT_DELAYED_WORK().
Signed-off-by: Tejun Heo t...@kernel.org
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Alan Stern st...@rowland.harvard.edu
Cc: linux-usb@vger.kernel.org
---
drivers/usb/core/hub.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1040,7 +1040,7 @@ static void hub_activate(struct usb_hub
*/
if (type == HUB_INIT) {
delay = hub_power_on(hub, false);
- PREPARE_DELAYED_WORK(hub-init_work, hub_init_func2);
+ INIT_DELAYED_WORK(hub-init_work, hub_init_func2);
schedule_delayed_work(hub-init_work,
msecs_to_jiffies(delay));
@@ -1194,7 +1194,7 @@ static void hub_activate(struct usb_hub
/* Don't do a long sleep inside a workqueue routine */
if (type == HUB_INIT2) {
- PREPARE_DELAYED_WORK(hub-init_work, hub_init_func3);
+ INIT_DELAYED_WORK(hub-init_work, hub_init_func3);
schedule_delayed_work(hub-init_work,
msecs_to_jiffies(delay));
return; /* Continues at init3: below */
--
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
Re: [PATCH v2 5/9] usb: don't use PREPARE_DELAYED_WORK
On Sat, 22 Feb 2014, Tejun Heo wrote:
Hello,
If this is actually safe, let's do it from the get-go.
Thanks!
--- 8 ---
PREPARE_[DELAYED_]WORK() are being phased out. They have few users
and a nasty surprise in terms of reentrancy guarantee as workqueue
considers work items to be different if they don't have the same work
function.
usb_hub-init_work is multiplexed with multiple work functions;
however, the work item is never queued while in-flight, so we can
simply use INIT_DELAYED_WORK() before each queueing.
It would probably be best to route this with other related updates
through the workqueue tree.
Lightly tested.
v2: Greg and Alan confirm that the work item is never queued while
in-flight. Simply use INIT_DELAYED_WORK().
Signed-off-by: Tejun Heo t...@kernel.org
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Alan Stern st...@rowland.harvard.edu
Cc: linux-usb@vger.kernel.org
---
drivers/usb/core/hub.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1040,7 +1040,7 @@ static void hub_activate(struct usb_hub
*/
if (type == HUB_INIT) {
delay = hub_power_on(hub, false);
- PREPARE_DELAYED_WORK(hub-init_work, hub_init_func2);
+ INIT_DELAYED_WORK(hub-init_work, hub_init_func2);
schedule_delayed_work(hub-init_work,
msecs_to_jiffies(delay));
@@ -1194,7 +1194,7 @@ static void hub_activate(struct usb_hub
/* Don't do a long sleep inside a workqueue routine */
if (type == HUB_INIT2) {
- PREPARE_DELAYED_WORK(hub-init_work, hub_init_func3);
+ INIT_DELAYED_WORK(hub-init_work, hub_init_func3);
schedule_delayed_work(hub-init_work,
msecs_to_jiffies(delay));
return; /* Continues at init3: below */
This should work okay. But while you're making these changes, you
should remove the INIT_DELAYED_WORK(hub-init_work, NULL) call in
hub_probe(). It is now unnecessary.
Is the cancel_delayed_work_sync(hub-init_work) call in hub_quiesce()
going to get confused by all this?
It's worth mentioning that the only reason for the hub_init_func3 stuff
is, as the comment says, to avoid a long sleep (100 ms) inside a work
routine. With all the changes to the work queue infrastructure, maybe
this doesn't matter so much any more. If we got rid of it then there
wouldn't be any multiplexing, and this whole issue would become moot.
Alan Stern
--
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
Re: [RFC PATCH v5 16/16] usb, xhci: flush initial hub discovery to gate port power control
On Fri, Feb 21, 2014 at 4:11 PM, Dan Williams dan.j.willi...@intel.com wrote:
Until all root hubs have been discovered and tier mismatch identified,
port power control is unreliable. When a USB3 port is paired with an
incorrect peer port there is chance a connected device will downgrade
its connection to its USB2 pins. The downgrade occurs when the USB3
port is powered off while the USB2 peer port is powered. Once the peer
ports are correctly assigned the kernel will prevent the disconnect
scenario. So, wait for the peer ports to be correctly assigned before
allowing a USB3 port to power off.
Now that khubd is a workqueue, and provided that khubd arranges to
re-queue enumeration work until all hubs (connected at driver load) are
enumerated, a drain_workqueue() operation will wait for all initial
discovery to complete. This requires the delayed hub-init_work to move
to khubd context. Care is taken to maintain parallel waiting for all
root hubs power on delays. However, since hub_quiesce() is called with
the device lock held it can no longer synchronously wait for init_work
to flush.
The workqueue subsystem enforces that no un-chained work (work queued
outside the workqueue context, e.g. hub_irq) may be queued for the
duration of the drain. Add infrastructure to defer and replay
kick_khubd() requests.
Not Signed-off, pending resolution of the locking horror in hub_quiesce()
---
drivers/usb/core/hcd.c |1
drivers/usb/core/hub.c | 88
++
drivers/usb/core/hub.h |4 +-
drivers/usb/core/port.c |4 ++
drivers/usb/host/xhci-pci.c |5 ++
drivers/usb/host/xhci-plat.c |4 ++
drivers/usb/host/xhci.c | 10 +
drivers/usb/host/xhci.h |5 ++
include/linux/device.h |5 ++
include/linux/usb.h |1
include/linux/usb/hcd.h |3 +
11 files changed, 112 insertions(+), 18 deletions(-)
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index b3ecaf32f2aa..f79bd06edc5f 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -2424,6 +2424,7 @@ struct usb_hcd *usb_create_shared_hcd(const struct
hc_driver *driver,
dev_dbg (dev, hcd alloc failed\n);
return NULL;
}
+ INIT_LIST_HEAD(hcd-khubd_defer);
if (primary_hcd == NULL) {
hcd-bandwidth_mutex = kmalloc(sizeof(*hcd-bandwidth_mutex),
GFP_KERNEL);
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index e0518af66af9..894d0e47b563 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -562,14 +562,20 @@ static void hub_release(struct kref *kref)
kfree(hub);
}
-static void kick_khubd(struct usb_hub *hub)
+static int khubd_draining;
+
+static void kick_khubd_unlocked(struct usb_hub *hub)
{
struct usb_interface *intf = to_usb_interface(hub-intfdev);
- unsigned long flags;
+ struct usb_hcd *hcd = bus_to_hcd(hub-hdev-bus);
- /* Suppress autosuspend until khubd runs */
- spin_lock_irqsave(hub_event_lock, flags);
- if (!hub-disconnected) {
+ if (hub-disconnected)
+ return;
+
+ if (khubd_draining) {
+ list_move_tail(hub-defer, hcd-khubd_defer);
The deferq needs to be global, not per hcd...
+ } else {
+ /* Suppress autosuspend until khubd runs */
usb_autopm_get_interface_no_resume(intf);
kref_get(hub-kref);
if (!queue_work(khubd_wq, hub-event_work)) {
@@ -577,6 +583,14 @@ static void kick_khubd(struct usb_hub *hub)
kref_put(hub-kref, hub_release);
}
}
+}
+
+static void kick_khubd(struct usb_hub *hub)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(hub_event_lock, flags);
+ kick_khubd_unlocked(hub);
spin_unlock_irqrestore(hub_event_lock, flags);
}
@@ -588,6 +602,33 @@ void usb_kick_khubd(struct usb_device *hdev)
kick_khubd(hub);
}
+void usb_drain_khubd(struct usb_hcd *hcd)
+{
+ static DEFINE_MUTEX(drain_mutex);
+ struct usb_hub *hub, *_h;
+
+ /* prevent concurrent drainers */
+ mutex_lock(drain_mutex);
+
+ /* flag khubd to start deferring work */
+ spin_lock_irq(hub_event_lock);
+ khubd_draining = 1;
+ spin_unlock_irq(hub_event_lock);
+
+ drain_workqueue(khubd_wq);
+
+ spin_lock_irq(hub_event_lock);
+ khubd_draining = 0;
+ list_for_each_entry_safe(hub, _h, hcd-khubd_defer, defer) {
+ list_del_init(hub-defer);
+ kick_khubd_unlocked(hub);
+ }
...otherwise deferred works from other hcds get dropped.
--
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
Your Payment Info
Attention/ this mail is to update you about your compensations fund,which has be forwarded to, western union head office for foreign transfer department.Call Mr. Anthony Frank Western Union Director for Your($1.200,000USD) EMAIL( western.unionuniononlinemoneytrans...@outlook.com )Send to him Your receiving information Note;without this requirements your transfer cannot be process. receiver full name… receiving country … address.. telephone number…. ID copy (if any) Best Regards, Operation Ms Linda. -- 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
Re: [RFC PATCH] xhci: Prevent runtime pm from autosuspending during initialization
On Fri, Feb 21, 2014 at 1:17 PM, Alan Stern st...@rowland.harvard.edu wrote: On Fri, 21 Feb 2014, Dan Williams wrote: Round 2: add usb 3 hcd usb_add_hcd() // secondary usb3 hcd hcd-self.root_hub = usb_alloc_dev() hcd-driver-reset(hcd) - xhci_gen_setup() if(primary_hcd) // false .. else pm_runtime_put_noidle(hcd-self.controller) // -1 usage, * register_root_hub(hcd) - usb_new_device(usb_dev) pm_runtime_set_active(udev-dev); pm_runtime_get_noresume(udev-dev); pm_runtime_use_autosuspend(udev-dev); pm_runtime_enable(udev-dev); ... pm_runtime_put_sync_autosuspend(udev-dev); // ok to trigger would trigger xhci_suspend if all usages were 0. *) unnecessary to trigger any suspend as we're just about to register the usb3 roothub. but we need to decrement the usage counter. Right, but I assume you'd want to hold the reference until after the hub is registered, otherwise there's still a chance we suspend right before register. So I'm saying hold the reference until the registration process takes its own. To be really safe about it, you should call pm_runtime_get_noresume at the start of xhci_pci_probe, and pm_runtime_put_noidle at the end Why _put_noidle? The fact that we suspend between registrations means the controller is getting suspend requests that we will block with _get_noresume. However, once probe is done our final put might be the only one to trigger the deferred suspension. I.e. just worried about the case where the controller's usage count is 0, but it remains active indefinitely. (as well as in the error return pathways). Sounds like an example case for a new devm_pm_runtime_get() api. -- 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
is it possible to temporarily not let user mode get hid input event
hi all: is there any kernel hid module parameter or test program can temporarily not letting user mode program not receiving hid event? 1. My hid kos are still inserted in. 2. the kernel usb driver is working well; that mean kernel usb driver still handle interrupt transaction. I just not want user mode program see the hid event for a while, Appreciate your kind help in advance, -- 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
Re: is it possible to temporarily not let user mode get hid input event
Hi On Sat, Feb 22, 2014 at 5:35 PM, loody milo...@gmail.com wrote: hi all: is there any kernel hid module parameter or test program can temporarily not letting user mode program not receiving hid event? 1. My hid kos are still inserted in. 2. the kernel usb driver is working well; that mean kernel usb driver still handle interrupt transaction. I just not want user mode program see the hid event for a while, For each connected HID device, there is a driver bound to it that reads the events and forwards them to HID core. What you can do, is to unbind a driver on a given device: echo your-device-name /sys/bus/hid/drivers/driver-name/unbind The device-name is the directory name in: /sys/bus/hid/devices/ The driver name is usually hid-generic but can be figured out for each device by looking at the driver symlink in it's directry. However, this is *really* just meant for debugging. This is not recommended for anything serious. There is no support for that and if you don't know what all this does, you shouldn't use it. There is no proper way to disable a single device in the kernel. User-space is supposed to control device-access so we probably won't add such features to the kernel. If you describe your use-case in more details, we can try to give hints how to get that working. Thanks David -- 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
Re: [PATCH v2 5/9] usb: don't use PREPARE_DELAYED_WORK
On 02/22/2014 10:14 AM, Alan Stern wrote:
On Sat, 22 Feb 2014, Tejun Heo wrote:
Hello,
If this is actually safe, let's do it from the get-go.
Thanks!
--- 8 ---
PREPARE_[DELAYED_]WORK() are being phased out. They have few users
and a nasty surprise in terms of reentrancy guarantee as workqueue
considers work items to be different if they don't have the same work
function.
usb_hub-init_work is multiplexed with multiple work functions;
however, the work item is never queued while in-flight, so we can
simply use INIT_DELAYED_WORK() before each queueing.
It would probably be best to route this with other related updates
through the workqueue tree.
Lightly tested.
v2: Greg and Alan confirm that the work item is never queued while
in-flight. Simply use INIT_DELAYED_WORK().
Signed-off-by: Tejun Heo t...@kernel.org
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Alan Stern st...@rowland.harvard.edu
Cc: linux-usb@vger.kernel.org
---
drivers/usb/core/hub.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1040,7 +1040,7 @@ static void hub_activate(struct usb_hub
*/
if (type == HUB_INIT) {
delay = hub_power_on(hub, false);
- PREPARE_DELAYED_WORK(hub-init_work, hub_init_func2);
+ INIT_DELAYED_WORK(hub-init_work, hub_init_func2);
schedule_delayed_work(hub-init_work,
msecs_to_jiffies(delay));
@@ -1194,7 +1194,7 @@ static void hub_activate(struct usb_hub
/* Don't do a long sleep inside a workqueue routine */
if (type == HUB_INIT2) {
- PREPARE_DELAYED_WORK(hub-init_work, hub_init_func3);
+ INIT_DELAYED_WORK(hub-init_work, hub_init_func3);
schedule_delayed_work(hub-init_work,
msecs_to_jiffies(delay));
return; /* Continues at init3: below */
This should work okay. But while you're making these changes, you
should remove the INIT_DELAYED_WORK(hub-init_work, NULL) call in
hub_probe(). It is now unnecessary.
Is the cancel_delayed_work_sync(hub-init_work) call in hub_quiesce()
going to get confused by all this?
It's worth mentioning that the only reason for the hub_init_func3 stuff
is, as the comment says, to avoid a long sleep (100 ms) inside a work
routine.
If a running hub init does not need to be single-threaded wrt
a different running hub init, then a single init work could be queued to
the system_unbound_wq which doesn't care about running times.
With all the changes to the work queue infrastructure, maybe
this doesn't matter so much any more. If we got rid of it then there
wouldn't be any multiplexing, and this whole issue would become moot.
--
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
Re: [RFC PATCH] xhci: Prevent runtime pm from autosuspending during initialization
On Sat, 22 Feb 2014, Dan Williams wrote: On Fri, Feb 21, 2014 at 1:17 PM, Alan Stern st...@rowland.harvard.edu wrote: On Fri, 21 Feb 2014, Dan Williams wrote: Round 2: add usb 3 hcd usb_add_hcd() // secondary usb3 hcd hcd-self.root_hub = usb_alloc_dev() hcd-driver-reset(hcd) - xhci_gen_setup() if(primary_hcd) // false .. else pm_runtime_put_noidle(hcd-self.controller) // -1 usage, * register_root_hub(hcd) - usb_new_device(usb_dev) pm_runtime_set_active(udev-dev); pm_runtime_get_noresume(udev-dev); pm_runtime_use_autosuspend(udev-dev); pm_runtime_enable(udev-dev); ... pm_runtime_put_sync_autosuspend(udev-dev); // ok to trigger would trigger xhci_suspend if all usages were 0. *) unnecessary to trigger any suspend as we're just about to register the usb3 roothub. but we need to decrement the usage counter. Right, but I assume you'd want to hold the reference until after the hub is registered, otherwise there's still a chance we suspend right before register. So I'm saying hold the reference until the registration process takes its own. To be really safe about it, you should call pm_runtime_get_noresume at the start of xhci_pci_probe, and pm_runtime_put_noidle at the end Why _put_noidle? The fact that we suspend between registrations means the controller is getting suspend requests that we will block with _get_noresume. However, once probe is done our final put might be the only one to trigger the deferred suspension. I.e. just worried about the case where the controller's usage count is 0, but it remains active indefinitely. Either _put_sync or _put_noidle would be okay. The reason is because the device core always calls pm_request_idle after probing a driver (see driver_probe_device()). (as well as in the error return pathways). Sounds like an example case for a new devm_pm_runtime_get() api. Maybe... Alan Stern -- 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
Re: [PATCH v2 5/9] usb: don't use PREPARE_DELAYED_WORK
On Sat, 22 Feb 2014, Tejun Heo wrote: On Sat, Feb 22, 2014 at 10:14:48AM -0500, Alan Stern wrote: Is the cancel_delayed_work_sync(hub-init_work) call in hub_quiesce() going to get confused by all this? Yeah, you can't cancel a work item which hasn't been initialzed. Maybe move init of the first work function there? I don't think it really matters tho. It's worth mentioning that the only reason for the hub_init_func3 stuff is, as the comment says, to avoid a long sleep (100 ms) inside a work routine. With all the changes to the work queue infrastructure, maybe this doesn't matter so much any more. If we got rid of it then there wouldn't be any multiplexing, and this whole issue would become moot. I don't really think that'd be necessary. Just sleeping synchronously should be fine. How many threads are we talking about? One thread per hub (no more than 10 on a typical system). The code in question is part of the hub driver's probe sequence. On Sat, 22 Feb 2014, Peter Hurley wrote: If a running hub init does not need to be single-threaded wrt a different running hub init, I'm not quite sure what that means, but the hub init threads are indeed independent of each other. then a single init work could be queued to the system_unbound_wq which doesn't care about running times. This sort of thing sounds like the best approach. Tejun, do you want to rewrite the patch, getting rid of the hub_init_func3 and HUB_INIT3 business entirely? Or would you like me to do it? Alan Stern -- 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
[GIT PULL] USB fix for 3.14-rc4
The following changes since commit 6d0abeca3242a88cab8232e4acd7e2bf088f3bc2: Linux 3.14-rc3 (2014-02-16 13:30:25 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ tags/usb-3.14-rc4 for you to fetch changes up to 5bf5dbeda2454296f1984adfbfc8e6f5965ac389: usb: chipidea: need to mask when writting endptflush and endptprime (2014-02-21 12:34:45 -0800) USB fixes for 3.14-rc4 Here are a number of USB fixes for reported issues for 3.14-rc4 The majority of these are for USB gadget, phy, and musb driver issues. And there's a few new device ids thrown in for good measure. Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org Ajay Kumar Gupta (1): usb: musb: host: Fix SuperSpeed hub enumeration Alan Stern (1): USB: EHCI: add delay during suspend to prevent erroneous wakeups Aleksander Morgado (1): USB: serial: option: blacklist interface 4 for Cinterion PHS8 and PXS8 Andrzej Pietrasiewicz (1): usb: gadget: fix NULL pointer dereference Daniel Mack (4): usb: musb: do not sleep in atomic context usb: musb: do not sleep in atomic context usb: musb: correct use of schedule_delayed_work() usb: musb: correct use of schedule_delayed_work() Felipe Balbi (1): usb: musb: fix obex in g_nokia.ko causing kernel panic Florian Fainelli (1): usb: gadget: bcm63xx_udc: fix build failure on DMA channel code Greg Kroah-Hartman (1): Merge tag 'fixes-for-v3.14-rc4' of git://git.kernel.org/.../balbi/usb into usb-linus Hans de Goede (3): phy-core: phy_get: Leave error logging to the caller phy-core: Don't propagate -ENOSUPP from phy_pm_runtime_get_sync to caller phy-core: Don't allow building phy-core as a module Josh Cartwright (1): usb: phy: msm: fix compilation errors when !CONFIG_PM_SLEEP Kishon Vijay Abraham I (1): phy: let phy_provider_register be the last step in registering PHY Matthieu CASTET (1): usb: chipidea: need to mask when writting endptflush and endptprime Peter Chen (1): usb: gadget: printer: using gadget_is_otg to check otg support at runtime Richard Weinberger (1): phy,phy-bcm-kona-usb2.c: Add dependency on HAS_IOMEM Roger Quadros (1): usb: musb: core: Fix remote-wakeup resume Sachin Kamat (1): usb: gadget: s3c2410_udc: Fix build error drivers/phy/Kconfig | 3 +- drivers/phy/phy-core.c | 14 - drivers/phy/phy-exynos-dp-video.c | 8 ++--- drivers/phy/phy-exynos-mipi-video.c | 10 +++ drivers/phy/phy-mvebu-sata.c| 10 +++ drivers/phy/phy-omap-usb2.c | 10 +++ drivers/phy/phy-twl4030-usb.c | 10 +++ drivers/usb/chipidea/udc.c | 4 +-- drivers/usb/gadget/bcm63xx_udc.c| 58 - drivers/usb/gadget/f_fs.c | 7 - drivers/usb/gadget/printer.c| 2 +- drivers/usb/gadget/s3c2410_udc.c| 2 +- drivers/usb/host/ehci-hub.c | 26 ++--- drivers/usb/musb/musb_core.c| 15 -- drivers/usb/musb/musb_host.c| 3 ++ drivers/usb/musb/musb_virthub.c | 26 - drivers/usb/musb/omap2430.c | 2 -- drivers/usb/phy/phy-msm-usb.c | 57 +--- drivers/usb/serial/option.c | 3 +- 19 files changed, 159 insertions(+), 111 deletions(-) -- 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
Re: [PATCH v2 5/9] usb: don't use PREPARE_DELAYED_WORK
Hey, Alan. On Sat, Feb 22, 2014 at 06:03:04PM -0500, Alan Stern wrote: then a single init work could be queued to the system_unbound_wq which doesn't care about running times. This sort of thing sounds like the best approach. Tejun, do you want to rewrite the patch, getting rid of the hub_init_func3 and HUB_INIT3 business entirely? Or would you like me to do it? I'll doing the minimal patch in this series and then following up with the update is probably better. I can put the patches in a separate branch so that it can be easily pulled. Thanks. -- tejun -- 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
USB Serial constantly polling
If I understand the USB Serial code correctly, at least open devices are constantly polled by 2 active URBs replaced immediately upon completion, except when the tty layer throttles them. With many of these devices, this creates significant USB bandwidth usage. At least one report found that it starts creating practical problems after 12 devices (on a BeagleBone), while adding a delay allows up to 60. Is there any reason not to have some small delay (perhaps user-configurable) between URB requests, at least while the device is not actively receiving data? If a patch is needed to implement this, what would be the recommended approach for a kernel complete-newbie? Thanks, Luke -- 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
Re: is it possible to temporarily not let user mode get hid input event
hi David: Thanks for your suggestion. 2014-02-23 0:56 GMT+08:00 David Herrmann dh.herrm...@gmail.com: Hi On Sat, Feb 22, 2014 at 5:35 PM, loody milo...@gmail.com wrote: hi all: is there any kernel hid module parameter or test program can temporarily not letting user mode program not receiving hid event? 1. My hid kos are still inserted in. 2. the kernel usb driver is working well; that mean kernel usb driver still handle interrupt transaction. I just not want user mode program see the hid event for a while, For each connected HID device, there is a driver bound to it that reads the events and forwards them to HID core. What you can do, is to unbind a driver on a given device: echo your-device-name /sys/bus/hid/drivers/driver-name/unbind The device-name is the directory name in: /sys/bus/hid/devices/ The driver name is usually hid-generic but can be figured out for each device by looking at the driver symlink in it's directry. However, this is *really* just meant for debugging. This is not recommended for anything serious. There is no support for that and if you don't know what all this does, you shouldn't use it. There is no proper way to disable a single device in the kernel. User-space is supposed to control device-access so we probably won't add such features to the kernel. If you describe your use-case in more details, we can try to give hints how to get that working. Sorry for not describing our situation clearer previously, The problem we met like below a. once plug in usb hid mouse and fast moving mouse b. the screen will get blur. We want to know whether the screen blur is caused by 1. the interrupt frequency of usb mouse is too high for our embedded system that make video decode slow 2. something wrong between hw cursor and video overlay. if we can deceive user mode program there is no mouse event, but kernel usb level still get hid interrupt transaction. We may clarify whether above 1) conclusion is correct. Appreciate your kind help :-) -- 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
