On Fri, 28 Nov 2003, Andrew Heaton wrote:
> I am trying to get a Freecom USB stick (0c76:0005) working with > an embedded linux build based on 2.4.22. > > I'm having problems getting it working, so I put in some > diagnostic code in my drivers submit_urb function to show the > urb->setup_packet data being sent. > > When I insert the stick for the first time, I see a strange > setup_packet going out (or attempting to go out - my USB chip > sees it as an error and refuses to send it). > > The data is below. flags=urb->transfer_flags, > length=urb->transfer_buffer_length, length2=urb->actual_length, > packets=urb->number_of_packets, interval=urb->interval > > Incidentally, if I unplug the stick and plug it back in I don't > get this odd setup_packet. I can do exactly the same with a USB > CDROM, with the same behaviour. If I plug in the stick, unplug > it, then plug in the CDROM I get another of these packets - so > it appears it is only sent on the first plugging in of a > particular device. > > Any ideas about what this is and why it's being sent? I don't > think it's doing any harm, but it's a bit confusing. > > Andrew > > > hci_submit_urb: flags 0 length 4 length2 0 packets 0 interval 0 > data A3 00 00 00 01 00 04 00
Setup Data: A3 00 00 00 01 00 04 00 --------------------------------------- Direction: Device-to-host Type: Class Recipient: Other --------------------------------------- bRequest: GET_STATUS
wValue: 0x0000
wIndex: For Port # 1
wLength: 4
> hci_submit_urb: flags 0 length 0 length2 0 packets 0 interval 0 > data 23 01 10 00 01 00 00 00
Setup Data: 23 01 10 00 01 00 00 00 --------------------------------------- Direction: Host-to-device Type: Class Recipient: Other --------------------------------------- bRequest: CLEAR_FEATURE
wValue: C_PORT_CONNECTION
wIndex: Port # 1
wLength: 0
> hci_submit_urb: flags 0 length 4 length2 0 packets 0 interval 0 > data A3 00 00 00 01 00 04 00 > hci_submit_urb: flags 0 length 4 length2 0 packets 0 interval 0 > data A3 00 00 00 01 00 04 00 > hci_submit_urb: flags 0 length 4 length2 0 packets 0 interval 0 > data A3 00 00 00 01 00 04 00 > hci_submit_urb: flags 0 length 4 length2 0 packets 0 interval 0 > data A3 00 00 00 01 00 04 00 > hci_submit_urb: flags 0 length 0 length2 0 packets 0 interval 0 > data 23 03 04 00 01 00 00 00 > hci_submit_urb: flags 0 length 4 length2 0 packets 0 interval 0 > data A3 00 00 00 01 00 04 00 > hci_submit_urb: flags 0 length 0 length2 0 packets 0 interval 0 > data 23 01 14 00 01 00 00 00
I don't recognize these peculiar commands. They are vendor- or class-specific. They aren't generated by the standard USB stack; you must have some customized driver loaded. Even more strange, they appear _before_ the device address has been set. Is it possible that they were meant for a different device, not the Freecom unit?
As I showed above with a decode from a CATC chief, they are setup commands to a hub, probably the one containing his device.
All this is normal if his device is connected via a hub.> hci_submit_urb: flags 0 length 0 length2 0 packets 0 interval 0 > data 00 05 02 00 00 00 00 00 > hci_submit_urb: flags 0 length 8 length2 0 packets 0 interval 0 > data 80 06 00 01 00 00 08 00 > hci_submit_urb: flags 0 length 18 length2 0 packets 0 interval 0 > data 80 06 00 01 00 00 12 00 > hci_submit_urb: flags 0 length 8 length2 0 packets 0 interval 0 > data 80 06 00 02 00 00 08 00 > hci_submit_urb: flags 0 length 39 length2 0 packets 0 interval 0 > data 80 06 00 02 00 00 27 00 > hci_submit_urb: flags 0 length 0 length2 0 packets 0 interval 0 > data 00 09 01 00 00 00 00 00
These commands are standard set-address, get-device-descriptor, get-configuration-descriptor, and set-configuration commands. They do come from the USB stack. Normally they would be the first commands sent to a newly-connected device.
> hci_submit_urb: flags 0 length 1 length2 0 packets 0 interval 0 > data A1 FE 00 00 00 00 01 00
Another peculiar non-standard command.
Regards, Steve.
------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
