hi David:
Thanks for your suggestion.
2014-02-23 0:56 GMT+08:00 David Herrmann :
> Hi
>
> On Sat, Feb 22, 2014 at 5:35 PM, loody 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
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
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 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 5bf5dbeda2454296f19
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 i
On Sat, 22 Feb 2014, Dan Williams wrote:
> On Fri, Feb 21, 2014 at 1:17 PM, Alan Stern 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
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
Hi
On Sat, Feb 22, 2014 at 5:35 PM, loody 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 dr
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 use
On Fri, Feb 21, 2014 at 1:17 PM, Alan Stern 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) // fals
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 Yo
On Fri, Feb 21, 2014 at 4:11 PM, Dan Williams 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
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 thin
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 i
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
fun
Signed-off-by: Alexander Shiyan
---
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/
16 matches
Mail list logo
