Received: by 2002:a05:6a10:a852:0:0:0:0 with SMTP id d18csp1490411pxy; Thu, 6 May 2021 09:01:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzXFV3FBWvvGMSggO9XRI7YXeho35NTM6xpN0aS3qoKGsLhe018/cj7+RGjUuJ166IA86ec X-Received: by 2002:a17:907:20f7:: with SMTP id rh23mr5156460ejb.276.1620316868723; Thu, 06 May 2021 09:01:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620316868; cv=none; d=google.com; s=arc-20160816; b=zQLRzG4BlCdA3e1Cv/4o+joGouBX005GF4L7eVi8aMBCCIccg9Bjp6po7ra2WKsyC4 W5ekiFK7+ak3raGyYalPfeGor1mlWZhiwsiQlEAAFnsIpEooTPHDVrdw31uhap1DdgGD RFzwID9u8Mx/cv49OufWT8bMARz8xEQk4+gA97xLgMfjFTLMp1CWGi+U98L1T+zJAvCo DnmQ+KRDJIcMlQTOYDt1TaHzFfEJVysP+dyIWFhoFbEv9CXBsrfDgeqWbaU/+IquoSXm +qYW3tXtMAswE6H3OcI8VPPnsyexZ8kSDlS8m/LbbTAeWyV6YrfysaMff09wkpls7u76 AlJQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=eqiHVj3O/k1/SVM0G+qNU5EayFbAdHLlHBkXTVoOPwM=; b=Ro0yCJOq1wHAoPXhwfcqjZmnIIFHcPovvZUyC+lvVReO8Dd+oumZuBbHKMJNADSH/h 9u/QWB/gtE2NDeKadG9SFczaOMfIBjNZPj521h7SDkZO2M+zIsAwjOxjxnYNwyXUbNZ1 h2BeJ74jRcRtFDMRACQart5XB3GrYTzmbptidHVg6pSnbTClfBMwFSZQV6KAORSG2F+h Wc1GaQ3+6lpafTf/d7Gc9zlDCaEvnRkbAtwOsl8n84LkH1z89azlfkk0XKQ9DgvLMyJj BSav9UVh0vmn2WGxiug685oFih3yUIUKHHu9caiFIcOrz58UJ8rzY7GsXe9I5TVVLQ+2 ++2A== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r10si2836646ejy.100.2021.05.06.09.00.43; Thu, 06 May 2021 09:01:08 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235231AbhEFQAm (ORCPT + 99 others); Thu, 6 May 2021 12:00:42 -0400 Received: from netrider.rowland.org ([192.131.102.5]:49621 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S235136AbhEFQAi (ORCPT ); Thu, 6 May 2021 12:00:38 -0400 Received: (qmail 741677 invoked by uid 1000); 6 May 2021 11:59:39 -0400 Date: Thu, 6 May 2021 11:59:39 -0400 From: Alan Stern To: Bjorn Helgaas Cc: Greg Kroah-Hartman , Paul Menzel , 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: <20210506155939.GA738638@rowland.harvard.edu> References: <20210506152300.GA1405893@bjorn-Precision-5520> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210506152300.GA1405893@bjorn-Precision-5520> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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