On hammer and derivatives, we particularly care about the time between attach and input devices ready to use.

Running these commands on soraka (kernel 4.4 @ befbaf46eea2be04ddce7eb03012dfac5183f0cb), we see:

ectool gpioset PP3300_DX_BASE 0; sleep 0.5; dmesg -c > /dev/null; echo plug > /dev/kmsg; ectool gpioset PP3300_DX_BASE 1
dmesg | sed -e 's/\[ *\([0-9\.]*\)\]/\1,/'

	Delta (s)	Time (s)	Kernel message
(0)	0.000000	55.093933	plug			
	0.274432	55.368365	usb 1-2: new full-speed USB device number 7 using xhci_hcd			
	0.439529	55.533462	usb 1-2: New USB device found	idVendor=18d1	idProduct=502b	bcdDevice= 1.00
	0.439537	55.53347	usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3	
	0.439541	55.533474	usb 1-2: Product: Hammer			
	0.439546	55.533479	usb 1-2: Manufacturer: Google Inc.			
	0.439550	55.533483	usb 1-2: SerialNumber: 2f0020000651524233353420			
	0.515353	55.609286	usb 1-2: USB disconnect	device number 7		
	0.798451	55.892384	usb 1-2: new full-speed USB device number 8 using xhci_hcd			
	0.963622	56.057555	usb 1-2: New USB device found, idVendor=18d1, idProduct=502b, bcdDevice= 1.00
	0.963633	56.057566	usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3	
	0.963637	56.05757	usb 1-2: Product: Hammer			
	0.963640	56.057573	usb 1-2: Manufacturer: Google Inc.			
	0.963643	56.057576	usb 1-2: SerialNumber: 2f0020000651524233353420			
(1)	0.965797	56.05973	input: Google Inc. Hammer as /devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0/0003:18D1:502B.0006/input/input15			
(2)	1.016636	56.110569	hammer 0003:18D1:502B.0006: input,hidraw1: USB HID v1.00 Keyboard [Google Inc. Hammer] on usb-0000:00:14.0-2/input0		
	1.019002	56.112935	input: Google Inc. Hammer as /devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.2/0003:18D1:502B.0007/input/input16			
	1.019249	56.113182	hid-multitouch 0003:18D1:502B.0007: input,hidraw2: USB HID v1.00 Device [Google Inc. Hammer] on usb-0000:00:14.0-2/input2

We are doing a bunch of stuff to optimize (0)->(1) (see b/36579698), and could reduce it to ~0.5 s.

There is a 50ms delay between (1) and (2), that is caused by this code path:

 - drivers/input/input.c: input_register_device
 - drivers/input/input.c: input_attach_handler => handler->connect
 - drivers/tty/sysrq.c: sysrq_connect
 - drivers/input/input.c: input_open_device => dev->open
 - drivers/hid/usbhid/hid-core.c: usbhid_open, here https://elixir.bootlin.com/linux/latest/source/drivers/hid/usbhid/hid-core.c#L723
	/*
	 * In case events are generated while nobody was listening,
	 * some are released when the device is re-opened.
	 * Wait 50 msec for the queue to empty before allowing events
	 * to go through hid.
	 */
	if (res == 0)
		msleep(50);

Disabling CONFIG_SYSRQ makes the 50ms delay disappear.

I wonder:
 a. If we can add a kernel/config option to make the 50ms disappear (if I understand b905811a49bcd6e6726ce5bbb591f57aaddfd3be "HID: usbhid: prevent unwanted events to be sent when re-opening the device", this should mostly not apply to the way we use input devices on Chrome OS)
 b. If we could reduce that 50ms delay to some multiple of the endpoint interval: many keyboards use long intervals (e.g. 24ms), but hammer uses ~2ms.
 c. If we could get the sysrq handler to be setup in a separate task/workqueue, as to not delay the main thread.