> > Hello, > > > > We are working with a host controller on a PowerPC embedded board. It is > > an EHCI host controller. However, there are no UHCI/OHCI host > > controllers on the board. Therefore, if a FS/LS device plugs onto the > > board, Linux will try to hand the port to a companion controller, which > > is not there, and this causes the EHCI host controller die (or maybe the > > port is marked dead?), and unplug the device causes no "disconnect" > > report. The host controller also does not respond to further plug in of > > a HS device. > > In theory this should work okay. It's not clear why your host > controller dies. It could be a bug in the hardware design. > I suspect a hardware bug too. Can you give me some pointer of what I should expect if the host controller does not support FS/LS, and a FS/LS device connects to the host controller? > > I wonder whether there is a way to configure the kernel such that if a > > FS/LS device plugged in (where the host controller will not enable the > > port), Linux will tell the user that "FS/LS devices are not supported", > > and do nothing. When the device disconnects, "disconnect" will be > > reported, and further plug-ins of HS devices can continue on. > > There is no way to do this, for a good reason: Hosts that don't support > FS/LS are in violation of the USB spec. > I know, but it seems make some sense on embedded systems. For example, a HS video camera, or a USB stick are the only expected devices that will connect to your system. However, sometimes, a user may mistakenly plug in a non-HS device. We would like to tell the user about his/her mistake, however, keep the host controller alive. > > Thanks, Pandita, that makes sense. I changed the two function > > registrations to NULL, and got following message if plug in a USB mouse: > > > > hub 1-0:1.0: Cannot enable port 1. Maybe the USB cable is bad? > > hub 1-0:1.0: Cannot enable port 1. Maybe the USB cable is bad? > > hub 1-0:1.0: Cannot enable port 1. Maybe the USB cable is bad? > > hub 1-0:1.0: Cannot enable port 1. Maybe the USB cable is bad? > > hub 1-0:1.0: unable to enumerate USB device on port 1 > > > > And the host controller is dead (not responsive) after this. > > Do you have CONFIG_USB_DEBUG enabled in your kernel? Have you tried > using usbmon to see what happens when the mouse is plugged in? > I do have USB_DEBUG configured in the kernel, however, I do not get any print on the embedded system. Strange though, if I put some printk's, and omit and "\n", some debug message will show up, however, not all of them. I did have USB_MON configured in, however, at kernel start up, it says: usbmon: debugfs is not available Thanks for your help, Julie. > Alan Stern > This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
