a160d93dda
Even if we are careful, it's still possible that we read spurious data from the keyboard, e.g. keystrokes. Namely, when we send the reset/disable command, there is a race before the command is pro- cessed. So we should always process data from the keyboard in a loop. We break it, when an ACK (0xfa) or a NAK (0xfe) is received, and warn on unexpected data unless it might be due to the mentioned race. This also gives us the opportunity to use command-specific timeouts which we take from Linux: 1s for the keyboard self-test (as there are keyboards that perform the test before acking the command) and 200ms for all other commands. Change-Id: I60a2643a8ff4b9231c63bf970c8749c97c7d8926 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/47083 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> |
||
|---|---|---|
| .. | ||
| coreinfo | ||
| external | ||
| libpayload | ||
| linuxcheck | ||
| nvramcui | ||
| Kconfig | ||
| Makefile.inc | ||