From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FZds9-0001uK-4O for qemu-devel@nongnu.org; Fri, 28 Apr 2006 21:03:45 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FZds8-0001u8-Hy for qemu-devel@nongnu.org; Fri, 28 Apr 2006 21:03:44 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FZds8-0001u5-By for qemu-devel@nongnu.org; Fri, 28 Apr 2006 21:03:44 -0400 Received: from [24.93.47.42] (helo=ms-smtp-03.texas.rr.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FZdvN-0001Wx-Lj for qemu-devel@nongnu.org; Fri, 28 Apr 2006 21:07:05 -0400 Received: from [192.168.0.11] (cpe-67-9-160-120.austin.res.rr.com [67.9.160.120]) by ms-smtp-03.texas.rr.com (8.13.4/8.13.4) with ESMTP id k3T13fqa003262 for ; Fri, 28 Apr 2006 20:03:42 -0500 (CDT) Message-ID: <4452BB67.8080902@austin.rr.com> Date: Fri, 28 Apr 2006 20:03:35 -0500 From: Lonnie Mendez MIME-Version: 1.0 Subject: Re: [Qemu-devel] Large USB patch References: <4447E811.1040403@gmx.de> <4448F1F6.4090609@austin.rr.com> <4448FF3F.3030009@austin.rr.com> <44490614.50406@austin.rr.com> <44490852.2080608@gmx.de> <44491659.30804@austin.rr.com> <44491F0A.2090608@austin.rr.com> <444926AC.3070104@austin.rr.com> <44494596.3070808@austin.rr.com> <4449F860.1060809@gmx.de> <444A3F7E.6070107@austin.rr.com> <444A5336.4040102@gmx.de> <444A578E.6000702@austin.rr.com> <444A5B65.8010104@gmx.de> <444AF6B7.1030606@austin.rr.com> In-Reply-To: <444AF6B7.1030606@austin.rr.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org lo. The bug with the usb hub is a simple fix. We're simply using handle_packet to pass USB_MSG_RESET when this should be passed to handle_msg: hw/usb-hub.c - line 388: case PORT_RESET: if (dev) { dev->handle_packet(dev, USB_MSG_RESET, 0, 0, NULL, 0); port->wPortChange |= PORT_STAT_C_RESET; The simple fix is to change the function call to dev->handle_msg(dev, USB_MSG_RESET) so that the state machine is correctly set up. I'm going to go over the port status bits with a fine comb to make sure everything is looking good. It also looks like we'll need to be able to propogate resume signal from usb_hub_attach to the uhci controller. This means putting the resume code in uhci_attach: // wakeup the controller if suspended if (s->cmd & UHCI_CMD_EGSM) { s->cmd |= UHCI_CMD_FGR; s->status |= UHCI_STS_RD; uhci_update_irq(s); } into a static function inside usb-uhci.c and then setting up a way of calling this when the controller needs to be resumed. If a device is set for remote_wakeup then it can call this function to resume the bus if necessary.