On 2012-05-28, at 11:55 AM, Alan Stern wrote: > > As far as I know, the only driver that uses the HID interface is > usbhid. It probably isn't a good model for what you want to do. Really? No freebies in there? Not even usbhid_submit_report? > > Maybe some of the files in drivers/usb/misc will be a closer match. found drivers/i2c/busses/i2c-diolan-u2c.c as a good starting point, do you agree? > > There is no such thing as a "control" report. Every input or output > report is supposed to be usable via both an interrupt and the control > endpoint. (See section 8.1 of the HID spec.) However not all HID > devices are fully compliant with the spec, and they don't all have > interrupt-out endpoints. ...did I mention I'm a USB noob!? :) I made a mistake, it's "feature request", so in the spec, report id 0x03 get gpio values is a "feature request in" report. http://pastebin.ca/2155190 is the info I could output from the cmd line. if you need, take a quick peak at the small PDF http://www.silabs.com/Support%20Documents/TechnicalDocs/AN495.pdf > > I don't know what you mean by "nested interrupt handler". For example the gpio-adp5588 driver has a threaded ISR callback which fetches the GPIO state of the chip through i2c, then maps each GPIO pin to it's related system IRQ number and calls handle_nested_irq() if it applies. This makes any pin of this gpio chip a source of interrupt to the system, it's "nested" because the irq client for a given pin will get it's threaded ISR handler through the handler of the 5588. > > If an input report is not available over the interrupt-in endpoint > (which would be a violantion of the HID spec) then you have no choice > but to poll it. Which seems to be the case based on the fact it's "feature request in". So that would mean I would have to "CPU-poll-it" to see if it changes, right? This pretty much kills the idea of declaring the GPIOs as source of interrupts then. > > There's a lot of kerneldoc in include/linux/usb.h. There are also some > documents available on the web that give reasonably good introductions > to Linux USB device driver programming (although they are all out of > date to some extent). The "Linux Device Drivers, 3rd ed." book > (freely available) has a chapter on it. Got it, I also have "essential linux device drivers" by Sreekrishnan Venkateswaran but I'am not sure about lots of stuff. So for example, if you take a look at the an495 pdf, once I have submitted report 0x10 (interrupt out) "Data read request" to the cp2112 to read data from an i2c slave, and I want to block until the data is ready, I understand that the returned data will come from report 0x13 (interrupt in) "data read response", and the chip send that on the USB wire spontaneously when it's got a token or something, right? If so, does the chip only get this "token" only if the device driver does something? Like actually asking for this report In any case, how do I block until this report has been fired by the chip? Using usb_interrupt_msg(usb_dev, usb_rcvintpipe(usb_dev,), ...) ?? I assume I'll want to do all my interactions with the chip synchronously, hence using usb_xyz_msg(dev, pipe, ). Does the host controller buffer the report if I am late getting the response? Thanks again for enlightening me! /jfd -- 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
