From: Alan Stern <stern@rowland.harvard.edu>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Paul Menzel <pmenzel@molgen.mpg.de>,
linux-usb@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
Mathias Nyman <mathias.nyman@intel.com>,
linux-pci@vger.kernel.org
Subject: Re: `quirk_usb_handoff_xhci` takes 60 ms with ASM1042
Date: Thu, 6 May 2021 11:59:39 -0400 [thread overview]
Message-ID: <20210506155939.GA738638@rowland.harvard.edu> (raw)
In-Reply-To: <20210506152300.GA1405893@bjorn-Precision-5520>
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
prev parent reply other threads:[~2021-05-06 15:59 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-05 7:57 `quirk_usb_handoff_xhci` takes 60 ms with ASM1042 Paul Menzel
2021-05-05 8:11 ` Greg Kroah-Hartman
2021-05-05 8:27 ` Paul Menzel
2021-05-05 8:33 ` Greg Kroah-Hartman
2021-05-05 12:15 ` Paul Menzel
2021-05-05 12:31 ` Greg Kroah-Hartman
2021-05-05 15:47 ` Bjorn Helgaas
2021-05-05 15:53 ` Greg Kroah-Hartman
2021-05-06 15:23 ` Bjorn Helgaas
2021-05-06 15:59 ` Alan Stern [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210506155939.GA738638@rowland.harvard.edu \
--to=stern@rowland.harvard.edu \
--cc=gregkh@linuxfoundation.org \
--cc=helgaas@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mathias.nyman@intel.com \
--cc=pmenzel@molgen.mpg.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).