于 2012年11月09日 04:35, Dave, Tushar N 写道:
-Original Message-
From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org]
On Behalf Of Joe Jin
Sent: Wednesday, November 07, 2012 10:25 PM
To: e1000-de...@lists.sf.net
Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org; Mary
于 2012年07月06日 17:38, Li Yu 写道:
于 2012年06月15日 16:51, Eric Dumazet 写道:
On Fri, 2012-06-15 at 13:37 +0800, Li Yu wrote:
Of course, I think that implementing them should not be a hard work :)
Em. I really do not know whether it is necessary to introduce to a new
syscall here. An alternative
Hi, all:
I encountered a problem of using sk_buff.
I used 2.4.20 kernel, when burst traffic come, the kernel will complain
a bug report at skbuff.c:316 later:
311 void __kfree_skb(struct sk_buff *skb)
312 {
313 if (skb->list) {
314 printk(KERN_WARNING "Warning: kfree_skb passed an skb still "
31
t seem I should give TASK_3 some extra credits
in some ways.
Sorry for such long mail and so bad English.
Good luck.
- Li Yu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kerne
Ingo Molnar wrote:
* Li Yu <[EMAIL PROTECTED]> wrote:
Eh, I wrong again~ I even took an experiment in last week end, this
idea is really bad! ;(
I think the most inner of source of my wrong again and again is
misunderstanding virtual time. For more better understanding this, I
Ingo Molnar wrote:
* Li Yu <[EMAIL PROTECTED]> wrote:
Also, I have want to know what's real meaning of
add_wait_runtime(rq, curr, delta_mine - delta_exec);
in update_curr(), IMHO, it should be
add_wait_runtime(rq, curr, delta_mine - delta_fair);
Is this just another
Ingo Molnar wrote:
* Li Yu <[EMAIL PROTECTED]> wrote:
Also, I have want to know what's real meaning of
add_wait_runtime(rq, curr, delta_mine - delta_exec);
in update_curr(), IMHO, it should be
add_wait_runtime(rq, curr, delta_mine - delta_fair);
Is this just another
Ingo Molnar wrote:
* Li Yu <[EMAIL PROTECTED]> wrote:
static void distribute_fair_add(struct rq *rq, s64 delta)
{
struct task_struct *curr = rq->curr;
s64 delta_fair = 0;
if (!(sysctl_sched_load_smoothing & 32))
return;
if (rq->nr_running) {
delt
ng);
Ingo, should we be replace "rq->nr_running" with "rq->raw_load_weight" here?
Good luck
- Li Yu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger
Li Yu wrote:
But as I observe by cat /proc/sched_debug (2.6.21.1, UP, RHEL4), I
found the all waiting fields often are more than zero, or less than zero.
IMHO, the sum of task_struct->wait_runtime just is the denominator of
all runnable time in some ways, is it right? if so, increasing
more precise. so what's
meaning for keeping the wait_runtime is zero-sum?
Good luck
- Li Yu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
ave a doubt when read this patch: in update_stats_enqueue(), It seem
that these statements in two brances of "if (p->load_weight >
NICE_0_LOAD)" are same,
is it on purpose?
Good luck
- Li Yu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Steven Rostedt wrote:
> Li Yu wrote:
>
>>> Now since mutexes can be defined by user-land applications, we don't
>>>
>> want a DOS
>>
>>> type of application that nests large amounts of mutexes to create a large
>>> PI cha
ime, as it walks the PI chain. More about this below.
After read the implementation of rt_mutex_adjust_prio_chain(), I found
the we really require maximin lock depth (1024 default), but I can not
see the check for more same locks duplication. Does this doc is
inconsistent with code?
Thanks in adv
ime, as it walks the PI chain. More about this below.
After read the implementation of rt_mutex_adjust_prio_chain(), I found
the we really require maximin lock depth (1024 default), but I can not
see the check for more same locks duplication. Does this doc is
inconsistent with code?
Thanks in adv
ut_input_init(hid, input_dev);
+ hidinput_lock_simple(hidinput);
+ input_unregister_device(hidinput->input);
+ hidinput->input = input_dev;
+ if (!(hid->quirks&HID_QUIRK_MULTI_INPUT))
+ hid_ff_init(hid);
+
Jiri Kosina wrote:
> On Mon, 16 Apr 2007, Li Yu wrote:
>
>
>> HID bus prototype 20070416
>>
>
> Hi Li,
>
> thanks for taking care. Well, the patch is quite huge, do you think you
> could split it into separate independent parts (use quilt or somet
are recommended
to wait to review that.
My friend yanghong buy a new bluetooth mouse, so I can test bluetooth
nowadays, Thanks him here. :D
Good luck.
- Li Yu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Hi,
It seem the hid-pidff driver also should be sticky.
Good luck
- Li Yu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read
should move inputs
member to hid_device, not in hid_driver. so if we removed one
hid_device, it do not disconnect all devices which its driver bind, just
only itself.
Now, usbhid works fine.
Good luck.
- Li Yu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
Dmitry Torokhov wrote:
>>> +int hid_open(struct hid_device *hid)
>>> +{
>>> + struct hid_transport *tl;
>>> + int ret;
>>> +
>>> + if (hid->driver->open)
>>> + return hid->driver->open(hid);
>>> + ret = 0;
>>> + spin_lock(&hid_lock);
>>> + tl = hid_transports[hid->bus];
>>> +
Dmitry Torokhov wrote:
>> +static int hid_bus_match(struct device *dev, struct device_driver
>> *drv) +{
>> +struct hid_driver *hid_drv;
>> +struct hid_device *hid_dev;
>> +
>> +hid_drv = to_hid_driver(drv);
>> +hid_dev = to_hid_device(dev);
>> +
>> +if (is_hid_driver_sticky(hid
ccess likely, or I failed to understand USB core ?! FIXING, The
fun also here.
The hiddump is good idea, I like, however, I think hidraw just is it.
the hiddump is one application of hidraw. is it right?
Good luck.
- Li Yu
hidbus.prototype.070404.patch.gz
Description: GNU Zip compressed data
g over code is
> usualy more efficient than just ranting random ideas :)
>
> Thanks,
>
>
Of course, It's no problem. but it must be tomorrow, two reasons:
1. The development PC is at my home, I am not SOHO.
2. After change from "flip-flopping", the patch need some
Nicolas Mailhot wrote:
>> Er, I also want to know what are drawbacks of "flip-flopping" ?
>>
>
> This will cause major havoc as soon as hot-plugging and apps listening to
> HAL events (xorg eventually) enter in play.
>
>
~_~
It really need some extra works in user space, but I do not thin
Marcel Holtmann wrote:
> The cleanest solution without a layer violation is that you can
> register a driver for a specific VID/PID and then report id (one or
> more). All
> reports with ids that we don't have a special driver for are handled by
> the default HID->input driver or handed over to hid
Dmitry Torokhov wrote:
>
> No, please don't do that. As soon as there is a special driver written
> for a device that device's VID/PID should be added to generic HID
> blacklist. This way udev will load the proper driver right away and
> there will not be any flip-flopping of input devices.
>
H
ain.
There have another type driver: the sticky driver, they will attach each
working device without clone or create new hid_device or input_dev. the
example is hiddev and hidraw.
Yes, this model imply there need more uevents: add, remove. Is this
model suitable? I think the essence of our discussi
Dmitry Torokhov wrote:
> On Thursday 29 March 2007 23:06, Li Yu wrote:
>
>> Dmitry Torokhov wrote:
>>
>>> On 3/28/07, Jiri Kosina <[EMAIL PROTECTED]> wrote:
>>>
>>>> The crucial thing here is that all reports but the ones tha
ur words.
PS: Have we need more than one shadow driver for same fundamental
driver? I do not think so.
Good luck.
- Li Yu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Jiri Kosina wrote:
> JFYI the preliminary version of the hidraw interface is now in the
> hid/usbhid git tree, and has also been in a few recent -mm kernels
> already.
>
>
The shadow driver support works now.
The most largest problem is HID/Bluetooth can not work now. And, I have
no any bluet
c driver" is
same with "shadow driver" too.
Er, What's mean of your "HUT", HID Usage Table? if so, I think I have already
explained we can do it.However, we should supply some convenient API for this
work. or HIT is other mysterious thing? ;)
> Regards
&
time.
Goodluck.
-Li Yu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
==
HID device simple driver interface
==
Note
If you just begin to study from writing input device driver, please see the
input-programming.txt, I am afraid this is not you want, do
ch_entry_safe(hidinput, next, &hid->inputs, list) {
+ hidinput_input_init(hid, input_dev);
+ hidinput_lock_simple(hidinput);
+ input_unregister_device(hidinput->input);
+ hidinput->input = input_dev;
+ if (!(hid->q
hile (!list_empty(&tmp_list)) {
+ list_del_init(tmp_list.next);
+ }
+ if (!input_dev)
+ return -ENOMEM;
+ list_for_each_entry_safe(hidinput, next, &hid->inputs, list) {
+ hidinput_input_init(hid, input_dev);
+ hidin
-12 13:29:28.0
+0800
@@ -0,0 +1,252 @@
+/*
+ * Microsoft Natural Ergonomic Keyboard 4000 Driver
+ *
+ * Version: 0.4.0
+ *
+ * Copyright (c) 2006 Li Yu <[EMAIL PROTECTED]>
+ */
+
+/*
+ * This program is free software; you can redistribute it and/or modify it
+ * under the term
meansure the performance of this patch ? I
have no any good idea for this.
Good luck.
Signed-off-by: Li Yu <[EMAIL PROTECTED]>
diff -Naurp linux-2.6.19/include/linux/prio_ceiling.h
linux-2.6.19.ceiling/include/linux/prio_ceiling.h
--- linux-2.6.19/include/linux/prio_ceiling.h 1970-01-01
break;
+ list_add_tail(&input_dev->node, &tmp_list);
+ }
+ while (!list_empty(&tmp_list)) {
+ list_del_init(tmp_list.next);
+ }
+ if (!input_dev)
+ return -ENOMEM;
+ list_for_each_entry_safe(hidi
ut_dev = input_allocate_device();
+ if (!input_dev)
+ break;
+ list_add_tail(&input_dev->node, &tmp_list);
+ }
+ while (!list_empty(&tmp_list)) {
+ list_del_init(tmp_list.next);
+ }
+ if (!input_dev
40 matches
Mail list logo
