From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gerd Hoffmann Subject: Re: [Patch V1 2/3] xen/usb: add capability for passing through isoc jobs to host devices Date: Wed, 09 Sep 2015 14:01:00 +0200 Message-ID: <1441800060.27149.50.camel@redhat.com> References: <1441277113-30693-1-git-send-email-jgross@suse.com> <1441277113-30693-3-git-send-email-jgross@suse.com> <1441373109.19555.7.camel@redhat.com> <55F019F6.30506@suse.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <55F019F6.30506@suse.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org To: Juergen Gross Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org, stefano.stabellini@eu.citrix.com List-Id: xen-devel@lists.xenproject.org Hi, > > So, the signaling needs to be different. The host adapter needs to > > signal somehow that it can handle async iso packets. One way would be > > to flag this per usb bus, another one per usb packet. Also all xen > > naming and the xen inlude should go away. BTW: does this build without > > xen-devel installed? > > Okay, I'll try to make it more generic. I think the async iso capability > should be a bus attribute. Makes sense. > > Can we get rid of the callbacks? By filling the USBPacket iovec with > > the iso request chunks for example? > > Difficult. One iso request chunk could require multiple iovec entries. Why multiple small iovecs instead of one big iovec? usb_host_req_complete_iso_xen() returns a single status for the whole USBPacket anyway ... > The RFC version tried to avoid the callbacks and there you didn't like > exposing the additional structures. -ENOPATCH. cheers, Gerd