On 05/19/2013 10:12 AM, Alan Stern wrote:
usb_kill_urb(dev->in.int_urb);Note that this call won't work if you are holding a spinlock.
ooh, thanks so much for that. Troubleshooting bugs that only occur upon an unexpected failure is not fun!
Using interrupt transfers for commands and responses is another bad design. No doubt it flows from the decision to support the HID interface.
Thanks. It's good to hear it from somebody more experienced. Once I read up on USB and the purpose of each type of endpoint, I thought that it was odd, but I'm learning something new, so what would I really know?
I don't know enough about the HID stack to answer this question. However, I suspect that the HID stack won't be a very good match to something which isn't really an HID device. Alan Stern
Well, good news! It turned out to just be one of those silly mistakes when setting up my in & out URBS! :) When calling fill_int_urb I accidentally used the usb_sndintpipe macro for both the in and out URB, so neither were actually attempting to receive! I changed this and the device is behaving as documented! Even better, I don't have to screw with any of the HID stack of protocol, w00t! Well, I still need to figure out power management, but just need to read up on it.
Thanks again! Daniel -- 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
