Dear list:
I'm not entirely certain, but I think I've a bug or two to report. At this
point, my USB device is under development and should imitate a USB mouse.
Problem 1)
When it is plugged into a Windows box, it works as expected, but when I
plug it into a Linux box it doesn't seem to finish grabbing all the
descriptors. Here is an output of kmsg (please excuse the extra output...
...I've added a bit while trying to understand the system):
<7>drivers/usb/host/uhci-hcd.c: 1800: wakeup_hc
<7>hub 1-0:1.0: port 2, status 101, change 1, 12 Mb/s
<7>hub 1-0:1.0: debounce: port 2: delay 100ms stable 4 status 0x101
<6>hub 1-0:1.0: new USB device on port 2, assigned address 14
<7>usb 1-2: new device strings: Mfr=0, Product=0, SerialNumber=0
<7>drivers/usb/core/usb.c: usb_hotplug
<4>usb 1-2: config 0 descriptor??<7>numconfigs = 1Configuration:
<4> bLength = 9
<4> bDescriptorType = 02
<4> wTotalLength = 0022
<4> bNumInterfaces = 01
<4> bConfigurationValue = 00
<4> iConfiguration = 00
<4> bmAttributes = a0
<4> bMaxPower = 304mA
However, when I change the configuration value to 0x01, there is no problem
with either system. I've noticed the code for the error message "config 0
descriptor??" is
if (cp && configuration == 0)
dev_warn(&dev->, "config 0 descriptor??\n");
which is of some confusion to me: the configuration value of '0' is
perfectly valid, I think. This may cause problems with other devices, too.
Problem 2)
The amount of returned descriptor is a bit touchy. As far as I can tell, by
the USB specification, when the host asks for 'x' number of bytes through
the wLength field, the device is expected to return a payload of 'x' of
bytes during the data phase. However, in practice this does not work as
expected. First, when the host requests the first 8 bytes of the device
descriptor, it hangs and reports a CRC error. Funny enough, it has actually
received all 8 bytes expected, but still the UHCI silicon generates a
CRC/Timeout error:
<7>drivers/usb/host/uhci-hcd.c: 1800: wakeup_hc
<7>hub 1-0:1.0: debounce: port 2: delay 100ms stable 4 status 0x101
<6>hub 1-0:1.0: new USB device on port 2, assigned address 17
<4>usb 1-2: control timeout on ep0in
<4>usb 1-2: actual length = 0
<7>drivers/usb/host/uhci-hcd.c: uhci_result_control() failed with status
440000 <4>[c5363240] link (053631e2) element (0532e100)
<4> 0: [c532e100] link (0532e140) e0 Stalled CRC/Timeo Length=7 MaxLen=7 DT0
EndPt=0 Dev=11, PID=2d(SETUP) (buf=0ad312c0)
<4> 1: [c532e140] link (0532e180) e3 SPD Active Length=0 MaxLen=7 DT1
EndPt=0 Dev=11, PID=69(IN) (buf=069a8364)
<4> 2: [c532e180] link (00000001) e3 IOC Active Length=0 MaxLen=7ff DT1
EndPt=0 Dev=11, PID=e1(OUT) (buf=00000000)
When hooked up to a Windows box, it does the same thing. So, despite the
odd behavior, I send the entire device descriptor even when only 8 bytes are
requested, and the initialization process continues.
However, when the configuration descriptor is requested things get more
out-of-sync. The windows system will not work if I send any more than 8
bytes (as requested). When working with Linux, the entire configuration
descriptor must be sent when the initial 8 bytes are requested, or the
initialization process just stops. Huh.
Does anyone have an explanation for this odd behavoir? If I am making a
silly mistake, or should eduacte myself more, please point me in the
direction of a book or other reading.
Thanks,
Ethan Mattor
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
