From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Brook Subject: Re: [Qemu-devel] [patch 0/2] USB UHCI global suspend / remote wakeup Date: Fri, 26 Nov 2010 12:09:47 +0000 Message-ID: <201011261209.47970.paul@codesourcery.com> References: <20101125170439.548474575@redhat.com> <20101126021512.GA18020@amt.cnet> <4CEF74B1.1030908@redhat.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , qemu-devel@nongnu.org, kvm , Matthew Garrett , Adam Jackson , Glauber de Oliveira Costa To: Gerd Hoffmann Return-path: Received: from mail.codesourcery.com ([38.113.113.100]:48614 "EHLO mail.codesourcery.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754024Ab0KZMKA (ORCPT ); Fri, 26 Nov 2010 07:10:00 -0500 In-Reply-To: <4CEF74B1.1030908@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: > On 11/26/10 03:15, Marcelo Tosatti wrote: > > On Fri, Nov 26, 2010 at 12:38:28AM +0000, Paul Brook wrote: > >>> This patch enables USB UHCI global suspend/resume feature. The OS will > >>> stop the HC once all ports are suspended. If there is activity on the > >>> port(s), an interrupt signalling remote wakeup will be triggered. > >> > >> I'm pretty sure this is wrong. Suspend/resume works based on physical > >> topology, i.e. the resume notification should go to the the port/hub to > >> which the device is connected, not directly to the host controller. > > > > You are correct in that USB HUB emulation does not propagate resume, but > > this does not make this patch incorrect. > > Well, it does. When the notification is port based our software model > should better reflect that, so we have the chance to add resume > propagation to the hub emulation later on. Exactly. The patch assumes the device is connected to a root hub port. This assumption is incorrect. The device should be sending the resume signal to the port/hub to which it is connected. If that hub is still active it will reactivate the port, and flag a port change notification in the normal manner. If the hub is also suspended it will propagate the resume notification upstream (which may or may not be the root hub). Paul From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=37236 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PLx7r-0000Ou-Gz for qemu-devel@nongnu.org; Fri, 26 Nov 2010 07:10:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PLx7p-0003Vl-Up for qemu-devel@nongnu.org; Fri, 26 Nov 2010 07:10:03 -0500 Received: from mail.codesourcery.com ([38.113.113.100]:36931) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PLx7p-0003Un-IH for qemu-devel@nongnu.org; Fri, 26 Nov 2010 07:10:01 -0500 From: Paul Brook Subject: Re: [Qemu-devel] [patch 0/2] USB UHCI global suspend / remote wakeup Date: Fri, 26 Nov 2010 12:09:47 +0000 References: <20101125170439.548474575@redhat.com> <20101126021512.GA18020@amt.cnet> <4CEF74B1.1030908@redhat.com> In-Reply-To: <4CEF74B1.1030908@redhat.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201011261209.47970.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: Matthew Garrett , kvm , Marcelo Tosatti , qemu-devel@nongnu.org, Glauber de Oliveira Costa , Adam Jackson > On 11/26/10 03:15, Marcelo Tosatti wrote: > > On Fri, Nov 26, 2010 at 12:38:28AM +0000, Paul Brook wrote: > >>> This patch enables USB UHCI global suspend/resume feature. The OS will > >>> stop the HC once all ports are suspended. If there is activity on the > >>> port(s), an interrupt signalling remote wakeup will be triggered. > >> > >> I'm pretty sure this is wrong. Suspend/resume works based on physical > >> topology, i.e. the resume notification should go to the the port/hub to > >> which the device is connected, not directly to the host controller. > > > > You are correct in that USB HUB emulation does not propagate resume, but > > this does not make this patch incorrect. > > Well, it does. When the notification is port based our software model > should better reflect that, so we have the chance to add resume > propagation to the hub emulation later on. Exactly. The patch assumes the device is connected to a root hub port. This assumption is incorrect. The device should be sending the resume signal to the port/hub to which it is connected. If that hub is still active it will reactivate the port, and flag a port change notification in the normal manner. If the hub is also suspended it will propagate the resume notification upstream (which may or may not be the root hub). Paul