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. Someone could try to change this and see :) > > > > Try changing your BIOS settings to not have "legacy" USB support > > > > in it, that could cause this transition to go faster, at the > > > > expense of not being able to use a USB device before Linux > > > > boots. > > > > > > The firmware of the Asus F2A85-M PRO allows to disable *legacy* > > > USB support for only the ASMedia ASM1042. And, thank you for the > > > suggestion, it helped. `quirk_usb_early_handoff()` does not show > > > up in the logs now, meaning it’s below 50 ms. And it is well > > > below: less than one millisecond. > > > > > > [ 0.308343] pci 0000:00:15.1: PCI->APIC IRQ transform: INT A -> IRQ > > > 16 > > > [ 0.308359] pci 0000:03:00.0: PCI->APIC IRQ transform: INT A -> IRQ > > > 17 > > > [ 0.308376] pci 0000:03:00.0: hc_init reached > > > [ 0.308380] pci 0000:03:00.0: second handshake done > > > [ 0.308384] pci 0000:03:00.0: third handshake done > > > [ 0.308395] PCI: CLS 64 bytes, default 64 > > > […] > > > [ 0.401722] Run /lib/systemd/systemd as init process > > > > Nice! > > > > Go blame your bios vendor now :) > > So the answer is "to make Linux boot faster, flip this BIOS switch > which means your USB devices no longer work while in BIOS"? > > I can see why this helps (BIOS never claims the xHCI, so OS can > immediately claim ownership), but it seems like a sub-optimal user > experience. Welcome to UEFI :) thanks, greg k-h
