On Fri, 17 May 2013, Daniel Santos wrote: > Hello. I'm working on a driver for a USB to SPI bridge chip > (Microchip's MCP2210) that acts as a HID device (generic subclass). Of > course, it can be used from user-space via hid-generic, but I'm not > really interested in that. I started this work from somebody else's > implementation that was a HID-based driver, but didn't like the > requirement to allocate 6k of data for the report for each 64 byte > rep/req so I started over as a plane-jane USB driver. I suppose this > was a bit naive, having never written a USB driver before, I guess I > relish challenges. Also, I'm intending to use this driver on a > low-memory embedded device. > > So I have the basics of my driver all working, sending 64 byte interrupt > URB requests (as per the datasheet - > http://ww1.microchip.com/downloads/en/DeviceDoc/22288A.pdf) and > receiving 64 byte response URBs, That doesn't make sense. Your driver submits URBs to the USB stack and waits for them to complete; it doesn't receive URBs from anywhere. Maybe you meant that your driver receives 64-byte response packets. But that doesn't make much sense either; it would require an extremely unusual HID device to send 64-byte responses. For example, a mouse or a keyboard generally sends responses in the 3- to 5-byte range. > except that the responses are always > all zeros. :( So I ran usbmon and observed the traffic when the > hid-core and hid-generic drivers use it and noticed quite a bit of > traffic on the control endpoint leaving me guessing that this is some > type of HID protocol that I naively omitted and that the chip just > doesn't respond on it's interrupt endpoints until some HID thing happens > on the control endpoint. The traffic you see is all standard HID requests. > My other thought was that I was perhaps I'm just not waiting long enough > before submitting the response URB (maybe the chip needs a little time > to process the request and just returns all zeros when it doesn't have > anything to say yet?) This depends on how you are using it. The HID protocol includes a request whereby the host tells the device not to send data if there have not been any changes. > -- but to test this theory, I'll need to implement > some type of bottom half (work queue or something). I am supplying the > interrupt interval specified by bInterval (which is 1, meaning 125 uS if > I understand correctly). If your device runs at high speed then 125 us is correct. If the device runs at full speed then 1 means 1 ms. > Anyway, if somebody has some advice, I would greatly appreciate it. I'm > combing through the USB 2 spec to try to find where the HID protocol is > covered, but maybe that's an entirely different spec? Advice greatly > appreciated!! See <http://www.usb.org/developers/hidpage/>. Alan Stern -- 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
