From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:40637) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qbtu1-0004ZD-Ty for qemu-devel@nongnu.org; Wed, 29 Jun 2011 08:29:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qbtu0-0004NH-9r for qemu-devel@nongnu.org; Wed, 29 Jun 2011 08:29:57 -0400 Received: from mx1.redhat.com ([209.132.183.28]:9165) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qbttz-0004ND-PS for qemu-devel@nongnu.org; Wed, 29 Jun 2011 08:29:56 -0400 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p5TCTtfP007782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 29 Jun 2011 08:29:55 -0400 Message-ID: <4E0B1AC0.1030002@redhat.com> Date: Wed, 29 Jun 2011 14:29:52 +0200 From: Gerd Hoffmann MIME-Version: 1.0 References: <1308943978-6152-1-git-send-email-hdegoede@redhat.com> <1308943978-6152-11-git-send-email-hdegoede@redhat.com> <4E0B0520.7040303@redhat.com> <4E0B0A32.7070907@redhat.com> In-Reply-To: <4E0B0A32.7070907@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 10/11] usb-uhci: Add support for being a companion controller List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Hans de Goede Cc: qemu-devel@nongnu.org Hi, > I agree, but there is a reason why I went with a usb_bus_register_companion > function instead of with a usb_bus_register_companion_port function, the > uhci controller needs to know how many companion controllers it has > (to report this in one of its registers). When we're registering > ports 1 by 1, it does not know. Good point. > Thinking more about this I think that the best approach would be to move > the port setup code (setting index, ops, speedmask, etc.) to > usb_bus_register_companion, and keep doing the entire registration > of all the ports in one single call. Would that work for you? Yes. Or have some helper function to fill the USBPort struct (which could be called by usb_register_port too). I just don't like the initialization being done by the host adapter in one case and by the usb core code in the other case as this is a bit confusing and makes the code harder to read. > This still leaves the building of the port pointers array, we could > pass in a stride parameter to usb_bus_register_companion and make it > build that list too, I'm not sure if that is a good idea though? Passing in the pointer array is fine with me. cheers, Gerd