On Fri, Dec 12, 2014 at 9:21 AM, David Herrmann <[email protected]> wrote: > Hi > > On Fri, Dec 12, 2014 at 6:18 PM, Andy Lutomirski <[email protected]> wrote: >> On Dec 12, 2014 3:05 AM, "David Herrmann" <[email protected]> wrote: >>> >>> So far, the solution is to use hid_device_io_start() and >>> hid_device_io_stop() in ->probe(). It's a hack to allow I/O during >>> ->probe(). Maybe your idea is the way to go, but unless someone >>> implements it, we're stuck with the current code. >> >> That should work. >> >> For normal HID drivers (those that don't start IO from probe), what >> happens if userspace starts IO before probe returns? Does the driver >> code prevent that somehow? > > It's only the async hid intr channel that is affected by this. > User-space cannot trigger any outgoing I/O on the intr channel. Only > the synchronous ctrl channel via SET_REPORT can be triggered, but due > to the synchronous nature we always allow I/O on it. >
I understand exactly one HID device, and that's U2F. In U2F, userspace will (directly or indirectly) use SET_REPORT, and the device responds immediately (ish) using the async intr channel. --Andy > Thanks > David -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
