Thank you all for your help, the problem is solved. The diff is against
kernel 2.4.21. I hope this information helps you!
Regards,
Jeff
===================================================================================
diff -u -r1.1.1.1 hub.c
--- drivers/usb/hub.c 20 Jul 2003 00:51:04 -0000 1.1.1.1
+++ drivers/usb/hub.c 27 Aug 2003 19:37:15 -0000
@@ -596,6 +596,7 @@
int i, status;
/* Reset the port */
+ usb_set_port_feature(hub, port + 1, USB_PORT_FEAT_ENABLE);
for (i = 0; i < HUB_RESET_TRIES; i++) {
usb_set_port_feature(hub, port + 1, USB_PORT_FEAT_RESET);
@@ -603,6 +604,7 @@
status = usb_hub_port_wait_reset(hub, port, dev, delay);
if (status != -1) {
usb_clear_port_feature(hub, port + 1, USB_PORT_FEAT_C_RESET);
+ usb_clear_port_feature(hub, port + 1, USB_PORT_FEAT_C_ENABLE);
return status;
}
===================================================================================
On Wed, 2003-08-27 at 10:58, David Brownell wrote:
> Jeffrey Baitis wrote:
> > Hi all:
> >
> > Are USB hubs generally sensitive to hardware and software reset timing?
> >
> > Curious if anyone has fixed a problem similar to the one that I'm
> > experiencing. I've got an integrated TI hub attached to the USB ports on
> > a board running embedded Linux. I reset the chip properly, but I do this
> > before Linux is ready to enumerate the device (the TI's documentation is
> > not very specific as to when you are supposed to reset the chip.)
> > Essentially, from power-on, all the pins of the TI hub are powered and
> > plugged into the USB bus.
> >
> > So, I broke out the reset pin, and manually tried resetting the TI hub
> > *after* Linux has gotten its OHCI controller going. However, I *still*
> > get the same message from the kernel log:
> >
> >
> > hub.c: new USB device builtin-2, assigned address 2
> > usb.c: USB device not accepting new address=2 (error=-145)
>
> Would you be using a MIPS processor, where that's "-ETIMEDOUT"?
> And does the same thing happen with non-hub devices?
> If so, then you've likely got an IRQ non-delivery problem.
>
>
> > It certainly seems like the hub is being sent USB reset commands, since
> > the first kernel log message is from a usb_hub_port_connect_change(). Is
> > there a consensus as to when the USB hub should be reset in hardware?
> > Ideas?
> >
> > Thanks very much
> >
> > -Jeff
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > [EMAIL PROTECTED]
> > To unsubscribe, use the last form field at:
> > https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
> >
>
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
