Hi The comment of hid_hw_start() (hid.h) mentions: * Call this in probe function *after* hid_parse. This will setup HW buffers * and start the device (if not deffered to device open). hid_hw_stop must be * called if this was successful. Especially the part in brackets allows the low-level driver to start the device without waiting for hid_hw_open() (bluetooth hid does this). However, hid_hw_start() does not synchronize hid and input startup, but instead first starts the hid layer followed by input. If the HID layer reports an event before the input layer is started, HIDINPUT will send the event to a nonexisting input device or may even dereference an invalid address. Same thing in hid_hw_stop(). An easy fix would be adding an atomic_t "ready" variable to the hid_device that is set to 1 after successful setup and hid_input_report must ignore every input until ready is 1. However, this does not work for hid_hw_stop() because we can't determine whether there is already a thread running inside hid_input_report() or similar. A more complex fix is a rwlock. hid_hw_start() locks it as writer and hid_input_report() and all other depending functions lock it as reader. We would still need something like a "ready" variable, but synchronization is also possible on hid_hw_stop() this way. Another more complex fix would be an input function like input_stop_reports() which will prevent the input instance from reporting any more events but still allow us to send events to it. Similar input_start_reports() for startup-synchronization. So we could register the input layer but prevent it from sending reports. Then we would start up the hid layer and after that we would start input reports. Same thing on shutdown... Any ideas? Regards David -- 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
