Fixing low-speed USB keyboard detection

[Soeren Moch]

Adding Marek as USB maintainer. Otherwise this non-patch-email may get
lost when sent to the mailing list only.

Soeren

On 25.02.20 18:45, Stefan wrote:
> Hello!
>
> I own a D-Link DBT-120 Bluetooth Adapter, which has a CSR firmware running in a so called “HID proxy mode”. This firmware pretends to be a USB keyboard (and mouse) and thus allows to use a Bluetooth keyboard in U-Boot.
>
> Unfortunately it acts as a low-speed device and there seems to be some well known troubles about low-speed USB keyboards. There is a FAQ entry for openSUSE about this: https://en.opensuse.org/HCL:Raspberry_Pi3#I_cannot_use_keyboard_in_U-Boot_and_Grub_but_it_works_in_Linux
>
> I spend some effort to solve this issue. There are three tiny changes to get my Bluetooth keyboard working reliably as a low-speed USB keyboard.
>
> Sometimes the Bluetooth adapter needs a bit longer to power on and send its descriptor. As I use a Raspberry Pi 3b, I modified include/configs/rpi.h to add "usb_pgood_delay=100\0" to the CONFIG_EXTRA_ENV_SETTINGS define. However this is actually not a necessary change, even without it, most of the time there is no issue.
>
> Then the Bluetooth adapter needs one millisecond delay before accepting a new address, to avoid the error “USB device not accepting new address”. This is in common/usb.c at line 1047:
>
> https://github.com/u-boot/u-boot/blob/master/common/usb.c#L1047
>
> 	dev->devnum = addr;
> 	mdelay(1);
> 	err = usb_set_address(dev); /* set address */
>
> And finally, assuming the use of CONFIG_SYS_USB_EVENT_POLL=y (which is the default), in common/usb_kbd.c at line 520 this first interrupt IN message must not be send:
>
> https://github.com/u-boot/u-boot/blob/master/common/usb_kbd.c#L520
>
> 	if (usb_int_msg(dev, data->intpipe, data->new, data->intpktsize,
> 			data->intinterval, false) < 0) {
> #endif
> 		printf("Failed to get keyboard state from device %04x:%04x\n",
> 		       dev->descriptor.idVendor, dev->descriptor.idProduct);
> 		/* Abort, we don't want to use that non-functional keyboard. */
> 		return 0;
> 	}
>
> Due to the #if stuff around, its a bit ugly. I solved it simply by modifying the if-statement in line 520:
>
> 	if (0) {
>
> With these two fixes my keyboard is working reliably. There is no need to press a key upfront and no error message any longer, as described for openSUSE. A chain-loaded GRUB-EFI is always usable now. I’m pretty sure that these changes will solve the issues for other low-speed USB keyboards as well.
>
>
> However, with that first interrupt IN message still sent, it seemed to me that there was a NYET loop in chunk_msg() in drivers/usb/host/dwc.c once complete_split got set. I guessed that “done += actual_len;” happens to often and possibly to early for an unfinished split transaction. With the recent fix 9dcab2c4d2cb50ab1864c818b82a72393c160236 introducing the nonblock argument, a split transfer gets restarted at a higher level, once there were to many NYET responses. But for this first interrupt IN message this nonblock argument is set to false, and in _submit_int_msg() we run into the timeout.
>
> If I understand it correctly, once a NYET message is received, it may take up to a millisecond before a response from a low-speed device is received (one low-speed frame). And a high-speed host has a frame length of 125 ms. That means that it can take up to 8 high-speed frames before a response from a low-speed device is received. Bit chunk_msg() returns already after > 4 high-speed frames. I would expect to wait at least 8 frames.
>
> The check after that first interrupt IN message got added by 5da2dc9789abecb1b018beb0c93f4c38c2985bc6 to workaround non-working keyboards. My suggested change will kind of revert that workaround. So there is some trade-off.
>
>
> Stefan