On Wed, May 05, 2021 at 05:53:18PM +0200, Greg Kroah-Hartman wrote: > On Wed, May 05, 2021 at 10:47:41AM -0500, Bjorn Helgaas wrote: > > On Wed, May 05, 2021 at 02:31:56PM +0200, Greg Kroah-Hartman wrote: > > > On Wed, May 05, 2021 at 02:15:26PM +0200, Paul Menzel wrote: > > > > Am 05.05.21 um 10:33 schrieb Greg Kroah-Hartman: > > > > > On Wed, May 05, 2021 at 10:27:52AM +0200, Paul Menzel wrote: > > > > > > Am 05.05.21 um 10:11 schrieb Greg Kroah-Hartman: > > > > > > > > > If the driver is built as a module, there should not be any "hot > > > > > > > path" here as the module is loaded async when the device is > > > > > > > discovered, right? > > > > > > obj-$(CONFIG_USB_PCI) += pci-quirks.o > > > > > > > > > > > > So all quirks are run independently of the USB “variant” > > > > > > (UHCI, OHCI, EHCI, xHCI). > > > > > > > > > > > > Indeed, this driver is built into the Linux kernel. > > > > > > > > > > > > $ grep USB_PCI .config > > > > > > CONFIG_USB_PCI=y > > > > > > > > > > > > So, should `pci-quirks.c` be split up to have more fine > > > > > > grained control? > > > > > > > > > > What control do you need here? > > > > > > > > Good question, as I do not know the USB spec. I’d say, > > > > disabling certain quirks, or just run them, when the actual > > > > driver is loaded. > > > > > > This is not a "quirk", it is part of how USB works. > > > > I agree, this doesn't look like a "quirk" in the sense of working > > around a hardware defect; the handoff is just a normal part of > > operating the device. But can you elaborate on why it must be done > > this way? > > > > I'm looking at the xHCI r1.2 spec, sec 4.22.1. It talks about the > > handoff synchronization process and says the OS driver shall use the > > defined protocol to request ownership before it uses the device. But > > AFAICT there's no specific "early-startup" requirement. > > > > quirk_usb_handoff_xhci() is in drivers/usb/host/pci-quirks.c, which is > > always built statically and the quirk runs during device enumeration, > > even if the xhcd driver itself is a module. It looks like we run the > > quirk even if we never load the xhcd driver. > > > > Why can't we just do the handoff in the xhcd driver probe? > > 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? 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? Bjorn
