On Thu, 13 Nov 2008, Jiri Slaby wrote:

Alan Stern wrote:

quoted

This suggests that a lot of the work in usbhid_start should be 
performed earlier, before calling hid_add_device.  After all, why 
bother registering a USB device on the input bus if usbhid isn't going 
to be able to drive it?

None of the code can be moved to the usbhid probe function, because all
of it depends on the driver's (potential) report_fixup.

However I suggest moving this test to the probe which ensures performing
the test early enough.

That makes sense.  It's the only failure mode in usbhid_start which
isn't a simple out-of-memory error.

Andi, could you test the attached patch?

--

Some devices have no input interrupt endpoint. These won't be handled
by usbhid, but currently they are not refused and reside on hid bus.

Perform this checking earlier so that we refuse to control such
a device early enough (and not pass it to the hid bus at all).

Signed-off-by: Jiri Slaby <redacted>

+	for (n = 0; n < interface->desc.bNumEndpoints; n++)
+		if (usb_endpoint_dir_in(&interface->endpoint[n].desc))
+			has_in++;
+	if (!has_in) {
+		dev_err(&intf->dev, "couldn't find an input interrupt "
+				"endpoint");
+		return -ENODEV;
+	}
+

Do you want to use usb_endpoint_is_int_in() instead?  It matches the 
error message more closely.

Alan Stern