From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33561) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VTd52-00087Z-Ey for qemu-devel@nongnu.org; Tue, 08 Oct 2013 15:36:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VTd4w-0005LH-Gq for qemu-devel@nongnu.org; Tue, 08 Oct 2013 15:36:28 -0400 Received: from mx1.redhat.com ([209.132.183.28]:4185) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VTd4w-0005L3-8n for qemu-devel@nongnu.org; Tue, 08 Oct 2013 15:36:22 -0400 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r98JaL2h008767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 8 Oct 2013 15:36:21 -0400 Message-ID: <52545EB3.7070802@redhat.com> Date: Tue, 08 Oct 2013 21:36:19 +0200 From: Hans de Goede MIME-Version: 1.0 References: <1379962447-5431-1-git-send-email-hdegoede@redhat.com> <1379962447-5431-5-git-send-email-hdegoede@redhat.com> <1380015472.3918.22.camel@nilsson.home.kraxel.org> In-Reply-To: <1380015472.3918.22.camel@nilsson.home.kraxel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 4/7] usb-hcd-xhci: Remove unused sstreamsm member from XHCIStreamContext List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: qemu-devel@nongnu.org Hi, On 09/24/2013 11:37 AM, Gerd Hoffmann wrote: > On Mo, 2013-09-23 at 20:54 +0200, Hans de Goede wrote: >> Signed-off-by: Hans de Goede > > Patch doesn't apply. Sorry, my bad, I had some other changes in my local tree which I was not yet ready to send and this depended on them. I'm ready to send the whole bunch of patches in one go now, which I'll do directly after this mail. > That are bits for the (not fully implemented yet) secondary stream > arrays btw. I know, but ... > We might complete the implementation instead of kicking > them out. Looking at the spec, I don't think any guest drivers will implement secondary streams, the lsa can handle any reasonable amount of streams just fine. The whole secondary stream thing is only interesting if you want to do insane amount streams, or have stream id ranges with holes in them. > I have no idea whenever there is a reasonable way to test > that though ... I agree, and I'm not sure there ever will be. So I vote for not worrying about secondary streams until we actually encounter a guest which uses them (at which point we should have a way to test through that guest). So my vote goes to just removing this cruft for now. Regards, Hans