Here are the piece of code from 2.6.22.1,
2817 static int hub_thread(void *__unused)
2818 {
2819 do {
2820 hub_events();
2821 wait_event_interruptible(khubd_wait,
2822 !list_empty(&hub_event_list) ||
2823
> If you accept the role, I'll send you my backlog of approximately 370
> requests ...
Stephen,
I can help to update it. we can work together to deal with so
many requests.
Regards
Jason Xiao
>
> --
> Vojtech Pavlik
> Director SuSE Labs
>
-
On 7/28/07, Vojtech Pavlik <[EMAIL PROTECTED]> wrote:
> On Fri, Jul 27, 2007 at 11:10:46AM -0700, David Brownell wrote:
>
> > I think we need a new usb.ids maintainer ... I get way too much
> > email from folk saying Vojtech hasn't responded so would I please
> > merge the IDs. (Vojtech, if you di
couldn't go sleep,
otherwise the whole driver would not work any more.This can explain
the question I raised before.Thanks.
Regards
Jason
On 7/11/07, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> Am Mittwoch, 11. Juli 2007 schrieb jidong xiao:
> > On 7/11/07, Oliver Neukum <[
On 7/11/07, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> Am Mittwoch, 11. Juli 2007 schrieb jidong xiao:
> > I see there are two routines, usb_unlink_urb and usb_kill_urb,the
> > latter one should be used for sync unlinking,this means it can go to
> > sleep,it won&#x
I see there are two routines, usb_unlink_urb and usb_kill_urb,the
latter one should be used for sync unlinking,this means it can go to
sleep,it won't return until the completion handler have finished.And
the former one could not go to sleep.But what's difference between
sync and async,I mean,why do
Still consider following piece of code, I see there is a change in
this part of code,here showed the same part of code but came from
different kernel version,one is sampled from kernel 2.6.10,while
another is sampled from kernel 2.6.21.
inside hub_events() sampled from drivers/usb/core/hub.c, 2.6.
What's the difference between event_bits and change_bits?
I just cannot understand why we need two variables.
188 struct usb_hub {
...
205 unsigned long event_bits[1]; /* status
change bitmask */
206 unsigned long change_bits[1]; /* ports with
Another separate issue,still focus on this piece of code,(inside
drivers/usb/core/hub.c, hub_configure())
> >
> > 570 switch (hdev->descriptor.bDeviceProtocol) {
> > 571 case 0:
> > 572 break;
> > 573 case 1:
> > 5
Great,thanks Alan and David.
Your answers are exactly what I really needed.
Alan,
According to your implication,I took a look at
rh_call_control(),and finally found such piece of code,I felt this
explains my question clearly.
376 case DeviceRequest | USB_REQ_GET_DESCRIPTOR:
377
On 6/29/07, Branden Sletteland <[EMAIL PROTECTED]> wrote:
> I am seeing an issue when going from kernel version 2.6.20.14 to
> 2.6.21 through 2.6.21.5 were my high speed devices are only being
> recognized as full speed devices, with error output on a 2.6.21 kernel
> stating:
>
> usb 3-1: new full
about device descriptor,according to usb spec 2.0,
1. A hub returns different descriptors based on whether it is
operating at high speed or full/low speed.A hub can report three
different sets of the descriptors.
2. A hub must operate at high-speed when its upstream facing port is
connected at high
Sorry I cannot find this in usb 2.0 spec.
But inside the code,drivers/usb/core/hub.c:
103 /* USB 2.0 spec Section 11.24.4.5 */
104 static int get_hub_descriptor(struct usb_device *hdev, void
*data, int size)
105 {
106 int i, ret;
107
108 for (i = 0; i < 3; i+
What's the difference between configuration and setting?Can anybody
show me any real examples, thank you.
Regards
Jason Xiao
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 exp
Calm down.
We should discuss this problem in a rational way. I believe there
should be more stories behind this mail. Even though I am not quite
clear about what happened before, but I guess probably you argued on
this some time back. So what are the current status?
Regards
Jason Xiao
On 6/20/07,
Maybe we can retry at this situation.
On 6/18/07, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I am looking at usb_sg_init().
>
> void usb_sg_wait (struct usb_sg_request *io)
> {
>int i, entries = io->entries;
>
>/* queue the urbs. */
>spin_lock_irq (&io-
I found this routine,
/**
* usb_register_root_hub - called by HCD to register its root hub
* @usb_dev: the usb root hub device to be registered.
* @parent_dev: the parent device of this root hub.
*
* The USB host controller calls this function to register the root hub
* properly with the USB
17 matches
Mail list logo
