On Mon, 27 Jan 2014, Lauri Peltonen wrote:
> I'm making some enhancements to hid/usbhid/hid-pidff.c to support more
> force feedback devices, but I've encountered some weird behaviour. I'm
> not sure whether it's a bug or something else.
>
> My changes depend on knowing some device information (like memory) in
> the initialization phase, and luckily hid-pidff reads the info from
> PID_POOL report in hid_pidff_init -> pidff_reset. [1] and [2]
>
> However, I noticed that the report struct never gets filled (all
> zeros), even though with usbmon I can see the ctrl message out and the
> report coming in with correct data (300 bytes of memory etc). I
> managed to locate the line which causes the report to be dropped in
> hid/hid-core.c , in hid_input_repor(..)t checking for
> driver_input_lock. [3] Commenting out the following lines "fixes" the
> issue, and the struct gets filled correctly. Anyways, I think that is
> not a real solution.
>
> if (down_trylock(&hid->driver_input_lock))
> return -EBUSY;
>
> Now, I wonder if there is a reason why the locking fails? Is the
> driver locked during the initialization and hid_hw_request(...
> HID_REQ_GET_REPORT) cannot be used?
Hi Lauri,
yes, that is the case. For the reasoning, and quite some more background
explanation of how this whole thing works, please read changelog of commit
4ea5454203d ("HID: Fix race condition between driver core and ll-driver").
Hopefully that should clarify your questions. If not, just ask :)
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
