On Mon, 26 Nov 2012, David Herrmann wrote: > The fix you are proposing actually looks pretty nice, although it puts > the burden of locking to the hid-driver instead of the hid-core. So > every .probe function must go sure that the lock is held when > returning. This means if you unlock the input-lock, you need to lock > it before calling return so hid-core can unlock it again. This opens a > small race-condition where the hid-core might drop important > input-events as input-lock is held during "return". Any ideas here? But why should we care deeply? The lost events wouldn't be the ones that are needed for initialization of the device, as all the probing as been finished already. So they would be 'regular' events sent by the device. And as the initialization hasn't been finished yet, it really can't be predicted which events make it and which don't. Thanks, -- 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
