freebsd stable - Aug 2003 - kern/55094: Intel USB 2.0 unrecognized (partial patch provided)

Saw your post on -stable about this, and decided to take a look since I'm 
about to get my hands on a similar (82801DB) motherboard.

If it's the USB 2.0 controller that's isn't being detected,
shouldn't ehci by
patched instead of uhci...?  You may want to give the attached, completely 
untested, patch a try.  I.e. it compiles on my box, but I don't have any 
hardware to actually test it on yet.  Might theoretically work depending on 
how closely Intel followed the EHCI spec.  Note that the patch includes 
entries for both the DB and EB variants of the chip.

I'm not sure why the code to pick up generic EHCI devices didn't find it
though.

Craig
-------------- next part --------------
--- sys/dev/usb/ehci_pci.c.orig	Thu Jul 31 23:22:28 2003
+++ sys/dev/usb/ehci_pci.c	Thu Jul 31 23:28:03 2003
@@ -80,6 +80,7 @@
 #define PCI_EHCI_VENDORID_AMD		0x1022
 #define PCI_EHCI_VENDORID_APPLE		0x106b
 #define PCI_EHCI_VENDORID_CMDTECH	0x1095
+#define PCI_EHCI_VENDORID_INTEL		0x8086
 #define PCI_EHCI_VENDORID_NEC		0x1033
 #define PCI_EHCI_VENDORID_OPTI		0x1045
 #define PCI_EHCI_VENDORID_SIS		0x1039
@@ -87,6 +88,13 @@
 #define PCI_EHCI_DEVICEID_NEC		0x00e01033
 static const char *ehci_device_nec = "NEC uPD 720100 USB 2.0
controller";
 
+#define PCI_EHCI_DEVICEID_INTEL_DB	0x24cd8086
+static const char *ehci_device_ich5_db +				"Intel 82801DB (ICH5) USB 2.0
controller";
+#define PCI_EHCI_DEVICEID_INTEL_EB	0x24dd8086
+static const char *ehci_device_ich5_eb +				"Intel 82801EB (ICH5) USB 2.0
controller";
+
 static const char *ehci_device_generic = "EHCI (generic) USB 2.0
controller";
 
 #define PCI_EHCI_BASE_REG	0x10
@@ -103,6 +111,10 @@
 	switch (device_id) {
 	case PCI_EHCI_DEVICEID_NEC:
 		return (ehci_device_nec);
+	case PCI_EHCI_DEVICEID_INTEL_DB:
+		return (ehci_device_ich5_db);
+	case PCI_EHCI_DEVICEID_INTEL_EB:
+		return (ehci_device_ich5_eb);
 	default:
 		if (pci_get_class(self) == PCIC_SERIALBUS
 		    && pci_get_subclass(self) == PCIS_SERIALBUS_USB
@@ -198,6 +210,9 @@
 		break;
 	case PCI_EHCI_VENDORID_CMDTECH:
 		sprintf(sc->sc_vendor, "CMDTECH");
+		break;
+	case PCI_EHCI_VENDORID_INTEL:
+		sprintf(sc->sc_vendor, "Intel");
 		break;
 	case PCI_EHCI_VENDORID_NEC:
 		sprintf(sc->sc_vendor, "NEC");

Sorry for the self-reply -- I forgot to mention that though the original 
question was about stable, the patch is against 5.1 release.  I'm not sure
if
ehci has been backported to stable or not (it wasn't in 4.8-RELEASE at 
least).

Craig

Craig,

Sorry for the incredibly late response.  General busyness you know.

On Thu, 31 Jul 2003, Craig Boston wrote:
> If it's the USB 2.0 controller that's isn't being detected,
shouldn't ehci by
> patched instead of uhci...?  You may want to give the attached, completely
> untested, patch a try.  I.e. it compiles on my box, but I don't have
any
> hardware to actually test it on yet.  Might theoretically work depending on
> how closely Intel followed the EHCI spec.  Note that the patch includes
> entries for both the DB and EB variants of the chip.
You are of course correct sir.  See below.
> I'm not sure why the code to pick up generic EHCI devices didn't
find it
> though.
Ignorance mostly.  This being the first machine I've ever had with USB
on it, I wasn't aware that USB 2.0 was handled by EHCI instead of the
OHCI or UHCI drivers (EHCI doesn't appear in the NOTES file and I
didn't think to make LINT until just a few minutes ago).  Once I
configured EHCI into the kernel all was well, and with your patch
it works swimmingly since it's even identified precisely.

So I for one can confirm that the patch you gave does indeed work.
Now if only I had the cash to buy a USB device to plug into the PC...

Thanks,
Brent Casavant

-- 
Brent Casavant			http://www.angeltread.org/
KD5EMB				-.- -.. ..... . -- -...
44 54'24"N 93 03'21"W 907FASL	EN34lv