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, 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.
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?) -- 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).
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!!
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
