tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Fixing the ubsa driver



Hi!

Since beginning of this year the ubsa driver has ceased working, and I was
trying to find the reasons since quite some time. I am using an Option N.V.
MC3G card for testing.

Today I would say that there are at least two bugs.

The first was already mentioned in this thread from February:
  http://mail-index.netbsd.org/current-users/2008/02/04/msg000760.html
Chavdar Ivanov and me both reported an NMI (entering the debugger) when
inserting a cardbus card in our HP NX6310.

With my card it looked like

ohci0 at cardbus0 function 0: vendor 0x1045 product 0xc861 (rev. 0x10)
NMI ... going to debugger
> cont
ohci0: interrupting at 10
ohci0: OHCI version 1.0, legacy support
usb5 at ohci0: USB revision 1.0
uhub5 at usb5
uhub5: Opti OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub5: 2 ports with 2 removable, self powered
ugen0 at uhub5 port 1
ugen0: Vodafone Vodafone Mobile Connect Card - 3G, rev 2.00/0.00, addr 2
[...]

I solved the NMI problem by the following hack in ohci_cardbus_attach():

--- cardbus/CVS/Base/ohci_cardbus.c     2008-06-28 14:09:48.000000000 +0200
+++ cardbus/ohci_cardbus.c      2008-07-11 21:26:17.000000000 +0200
@@ -132,8 +132,10 @@
        }
 
        /* Disable interrupts, so we don't can any spurious ones. */
+#if 0
        bus_space_write_4(sc->sc.iot, sc->sc.ioh, OHCI_INTERRUPT_DISABLE,
                          OHCI_ALL_INTRS);
+#endif
 
        sc->sc_cc = cc;
        sc->sc_cf = cf;

This is certainly plain wrong. But it helps for the moment. Maybe somebody
else has a better idea what to investigate?


The second problem was that the ubsa device is no longer attached, but ugen.
This is caused by some modifications done by ichiro in January for the uhmodem
driver. For reasons I don't understand ubsa is an "usbifif" now:
#attach ubsa at usbdevif 
attach  ubsa at usbifif

But the USB_MATCH_START and USB_ATTACH_START macros in ubsa.c were not changed
to USB_IFMATCH_START/USB_IFATTACH_START after that. I fixed that, and now ubsa
is recognized again.

Unfortunately there are more problems. Now ucom was no longer recognized,
because usbd_set_config_index() failed.
It was passed an UBSA_DEFAULT_CONFIG_INDEX of 1 (why?), but there is only
bNumConfigurations = 1 configuration. So the check failed. I fixed that by
defining UBSA_DEFAULT_CONFIG_INDEX as 0 (without knowing what it means!),
and also changed USB_UNCONFIG_NO into USB_UNCONFIG_INDEX in
usbd_set_config_config, which looked like another bug. The diffs:

--- usb/CVS/Base/ubsa.c 2008-06-28 14:09:59.000000000 +0200
+++ usb/ubsa.c  2008-07-11 20:55:18.000000000 +0200
@@ -150,7 +150,7 @@
 
 USB_MATCH(ubsa)
 {
-       USB_MATCH_START(ubsa, uaa);
+       USB_IFMATCH_START(ubsa, uaa);
 
        return (ubsa_lookup(uaa->vendor, uaa->product) != NULL ?
                UMATCH_VENDOR_PRODUCT : UMATCH_NONE);
@@ -158,7 +158,7 @@
 
 USB_ATTACH(ubsa)
 {
-       USB_ATTACH_START(ubsa, sc, uaa);
+       USB_IFATTACH_START(ubsa, sc, uaa);
        usbd_device_handle dev = uaa->device;
        usb_config_descriptor_t *cdesc;
        usb_interface_descriptor_t *id;
--- usb/CVS/Base/ubsavar.h      2008-06-28 14:09:59.000000000 +0200
+++ usb/ubsavar.h       2008-07-11 20:55:12.000000000 +0200
@@ -55,7 +55,7 @@
 
 #define        UBSA_MODVER             1       /* module version */
 
-#define        UBSA_DEFAULT_CONFIG_INDEX       1
+#define        UBSA_DEFAULT_CONFIG_INDEX       0
 #define        UBSA_IFACE_INDEX_OFFSET 0
 
 #define        UBSA_INTR_INTERVAL      100     /* ms */
--- usb/CVS/Base/usb_subr.c     2008-06-28 14:10:00.000000000 +0200
+++ usb/usb_subr.c      2008-07-11 20:53:39.000000000 +0200
@@ -555,7 +555,7 @@
        DPRINTFN(5,("usbd_set_config_index: dev=%p index=%d\n", dev, index));
 
        if (index >= dev->ddesc.bNumConfigurations &&
-           index != USB_UNCONFIG_NO) {
+           index != USB_UNCONFIG_INDEX) {
                /* panic? */
                printf("usbd_set_config_index: illegal index\n");
                return (USBD_INVAL);

Now there are ubsa0..2 and ucom0..2 attached, which seems not correct to me.
I remember last year it was only one.

Why does ubsa have to be an usbifif instead of an usbdevif anyway?

I have absolutely no experience with the USB source! Can anybody else make
any sense out of this?

Would be nice to get ubsa fixed for 5.0 (it worked with early 4.99.x
versions).

Thanks in advance!

-- 
Frank Wille


Home | Main Index | Thread Index | Old Index