On Thu, May 06, 2021 at 10:23:00AM -0500, Bjorn Helgaas wrote: > On Wed, May 05, 2021 at 05:53:18PM +0200, Greg Kroah-Hartman wrote: > > I think, if we don't do the handoff, then the BIOS/firmware tries to > > send the OS fake keyboard/mouse commands, and Linux isn't ready for that > > as we didn't allow hotplug PS/2 stuff. But I could be wrong, it's been > > a long time since we did that logic. > > I have no idea what "BIOS/firmware sending OS fake keyboard/mouse > commands" means. From the OS point of view, does that look like USB > events that cause PCI interrupts? PS/2 interrupts? Are these > commands caused by the user typing or moving the mouse? Or does BIOS > fabricate commands for other reasons? Think of an old MSDOS operating system without USB support. The BIOS tries to be helpful by translating mouse and keyboard input it receives over USB into PS/2 events that the operating system can handle. Originally this was done using SMI; now it presumably is still a legacy part of UEFI. > The way you describe it, this *sounds* like a race, where Linux > mishandles commands that happen before the handoff quirk. Do you > remember what happens if BIOS sends a fake command before Linux is > ready for it? Unexpected interrupt? I would be surprised if anybody still knows. :-) Perhaps a reasonable experiment would be to boot a kernel with PS/2 support but not USB support (or at least, without CONFIG_USB_PCI) and see what happens when you type on the USB keyboard or move the USB mouse. It might very well turn out that the handoff operation can safely be delayed until driver probe time. Alan Stern
