Received: by 2002:a05:6a10:a852:0:0:0:0 with SMTP id d18csp270052pxy; Wed, 5 May 2021 01:35:04 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzKh0lTlE2VaSxKlnu3GdwO11UUOLmS7lDbGLUCNUkQuuSEG4E39SvL5yeOoVJlxQfA+KFs X-Received: by 2002:a17:90a:cf09:: with SMTP id h9mr10383949pju.186.1620203704050; Wed, 05 May 2021 01:35:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620203704; cv=none; d=google.com; s=arc-20160816; b=ndPOsUq0U4S8m4pcknYcaCgHrflp3/Q92CJr2WAVsdd6XhBl//DRawGulXGSyESEbb x7zh5XqkI0El5DMwmW/EpPlsIEEVuufnv0EHu2Ceuf6m+29ktw5wIjqdafg8U7QsjUIC YuJzMPGEaGUYNjICaRXh944hm4pDBs98EDPdbp+h5dH3u5Mnj2njHVPQRZH7kHUBNHjE 7iOE9qAEzThqu3KUQ4GbJ8flgSNbpDLETV9ytxKULpYtCE1dTZd8zaz+7Go1J8HiVn3Q DYJslCZMPtRhS2CjhIWgw8A3C/GCwJ0eHlgE3iNe4bjld1vYWcqgiS6qmw5x9Mx+m8NE LVCQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=ogNe/Oq7iOFLRT6VHdxQa3UZBpBJUHr/HgrjW397vOM=; b=H8ZAtsPS/lR/5bt9JzmdGQZoxuSTxv3BrXZUYm6pM1rFp/17xUgK6cSxkWHeThU2RU jvzlhyNY8bDED6vnNn5mpsuuo1fk/FFwKx1v94Mi9l/vsRTdTfpMMJfPofJoQ+uiO0h3 Kkj84m30Mp6iEK+SAWuduzlh2gvFmqptjowL6XABLYxIVwyR1qqOi83DE2QGfZfYWFWU SjTrFnA5YkX8WsahlCVOlu0MEILYOqva9oPHphK1QxW8/BJwfKFXg0VsDSY4yWC8rnLu GwjNn/0egRJgfrupxhsDGS3ce0POEZvaADDAB5Cq7PgKTCTDxo2r+0nLfkgXOgZS6/IQ h99A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=vKfo4nIj; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e6si6595470pgh.334.2021.05.05.01.34.51; Wed, 05 May 2021 01:35:04 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=vKfo4nIj; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231936AbhEEIe4 (ORCPT + 99 others); Wed, 5 May 2021 04:34:56 -0400 Received: from mail.kernel.org ([198.145.29.99]:56224 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231637AbhEEIez (ORCPT ); Wed, 5 May 2021 04:34:55 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 167A16112F; Wed, 5 May 2021 08:33:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1620203638; bh=T7WhWpBDSvK2RonC3VBugnps8qdhujaF26UAPEuaQ20=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=vKfo4nIjOv4yx7NDIfQ+6i0iJu97Ctoob9rdboCpQUEaL3NIEQvIV3rPO0227+U48 7kiHMweWBw9DYcNAmJm3gHjFcwUFIjDWx/tpL8iuUanD1bm+paX0kjmO6diNHOorLL H8/9QFJkpoRWXX4iN76x4JxBRw1YXevlzypKAqgg= Date: Wed, 5 May 2021 10:33:56 +0200 From: Greg Kroah-Hartman To: Paul Menzel Cc: linux-usb@vger.kernel.org, LKML , Mathias Nyman , linux-pci@vger.kernel.org Subject: Re: `quirk_usb_handoff_xhci` takes 60 ms with ASM1042 Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 05, 2021 at 10:27:52AM +0200, Paul Menzel wrote: > Dear Greg, > > > Thank you for the quick reply. > > Am 05.05.21 um 10:11 schrieb Greg Kroah-Hartman: > > On Wed, May 05, 2021 at 09:57:44AM +0200, Paul Menzel wrote: > > > > On an Asus F2A85-M PRO, BIOS 6601 11/25/2014, with an ASM1042 SuperSpeed USB > > > Host Controller [1b21:1042], and the xHCI drivers built as modules > > > > > > CONFIG_USB_XHCI_PCI=m > > > CONFIG_USB_XHCI_HCD=m > > > > > > `quirk_usb_handoff_xhci` takes 60 ms, which is 15 % of the time to reaching > > > `run_init_process()`. I addded some prints, showing the f > > > > > > [ 0.308841] pci 0000:03:00.0: PCI->APIC IRQ transform: INT A -> IRQ 17 > > > [ 0.369858] pci 0000:03:00.0: handshake done with timeout = 0 > > > [ 0.369862] pci 0000:03:00.0: hc_init reached > > > [ 0.369865] pci 0000:03:00.0: second handshake done > > > [ 0.369869] pci 0000:03:00.0: third handshake done > > > [ 0.369909] pci 0000:03:00.0: quirk_usb_early_handoff+0x0/0x670 took 59661 usecs > > > […] > > > [ 0.415223] Run /lib/systemd/systemd as init process > > > > > > Is there a way to optimize this, or move it out “the hot path”? > > > > That's the hardware taking so long, all that function does is make some > > PCI calls to the device. > > In your experience, do most devices take that long? No idea, it all depends on the device. And is 60ms really that long to initialize the USB controller? That's a complex beast. > > 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? And yeah, I see, but this code has to be run at early-startup to match the USB spec requirements for handing off the USB control from the BIOS/firmware/whatever, to the kernel. 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. And is this really the slowest thing at startup for you that it is the last thing that needs to be optimized? > > What is waiting for this module to load in order to cause your init to > > stall? Perhaps fix your initramfs logic or build the driver into the > > kernel itself to take it off of this "load all the modules and wait" > > path? > > Sorry, for causing some confusion. But as written above, this all happens > before the initrd is involved. No problem, I was confused as well :) thanks, greg k-h