From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=41255 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OGuN7-0003JJ-5c for qemu-devel@nongnu.org; Tue, 25 May 2010 09:40:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OGuN5-0001wS-Op for qemu-devel@nongnu.org; Tue, 25 May 2010 09:40:41 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]:53490) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OGuN5-0001tJ-KZ for qemu-devel@nongnu.org; Tue, 25 May 2010 09:40:39 -0400 Received: from [10.89.12.35] ([10.89.12.35]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o4PDeFjX001884 for ; Tue, 25 May 2010 13:40:16 GMT Message-ID: <4BFBD33F.7010403@cisco.com> Date: Tue, 25 May 2010 07:40:15 -0600 From: "David S. Ahern" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] RFC: ehci -> uhci handoff suggestions List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel USB 2.0 leverages companion UHCI or OHCI host controllers for full and low speed devices. I do not see an appropriate means for doing that bus transition and could use some suggestions. I've read through the code for the "legacy" path in handling USB devices (-usbdevice CLI arg and usb_add monitor command), and I am now working on the new path (now that I know about it). As I understand the code at this point it is a top down setup: device added, bus found, device attached. -------------------- | Qemu USB admin | - adding/removing devices | interface | - showing device list -------------------- | -------------------- | USB controller | -------------------- | -------------------- | USB device model | - emulated devices (e.g., hw/usb-serial) | (or driver ) | - host devices -------------------- ie., key point is the expectation that the bus to which the device is assigned is known early in the code path. For USB devices the bus to attach it to should be determined automatically when the device is attached. Something along the lines of: -------------------- | Qemu USB admin | | interface | -------------------- | -------------------- -------------------- | EHCI controller |--->| UHCI / OHCI | -------------------- -------------------- | | -------------------- -------------------- | USB device model | | USB device model | | (or driver ) | | (or driver ) | -------------------- -------------------- high speed full / low speed To know which bus to attach it to the device needs to be queried/probed for basic information - something the current architecture does not have. Suggestions? David P.S. I skimmed the USB 3.0 spec and it has the same design: super speed devices are attached to the new 3.0 controller, high speed to ehci and low/full to uhci/ohci.