All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@web.de>
To: Hans de Goede <hdegoede@redhat.com>
Cc: qemu-devel <qemu-devel@nongnu.org>, Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] usb-redir: Allow to attach USB 2.0 devices to 1.1 host controller
Date: Mon, 17 Sep 2012 11:18:42 +0200	[thread overview]
Message-ID: <5056EAF2.60205@web.de> (raw)
In-Reply-To: <5056E876.9010400@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 2444 bytes --]

On 2012-09-17 11:08, Hans de Goede wrote:
> Hi,
> 
> On 09/15/2012 06:27 PM, Jan Kiszka wrote:
>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>
>> This follows the logic of host-linux: If a 2.0 device has no ISO
>> endpoint and no interrupt endpoint with a packet size > 64, we can
>> attach it also to an 1.1 host controller. In case the redir server does
>> not report endpoint sizes, play safe and remove the 1.1 compatibility as
>> well.
>>
>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> 
> Interesting thanks for the patch. I like the approach you took (simple
> code),
> but unfortunately it won't work, if you look at usbredir_device_connect(),
> where you do the dev->dev.speedmask |= USB_SPEED_MASK_FULL, it also
> actually attaches the device to the controller, from which point on the
> guest will see the device.
> 
> What happens on the wire is that the usbredir-host sends (in order):
> -ep_info + interface_info
> -device_connect message
> 
> So your clearing of the speed-mask will never trigger, unless ep-info
> gets repeated later (which it does under certain circumstances).

Hmm, what a pity...

> 
> I suggest instead changing the code to set a "fullspeed_compatible" flag
> in struct USBRedirDevice from usbredir_device_disconnect(), clear that
> flag from usbredir_ep_info and use it to add to the mask in
> usbredir_device_connect().

OK.

> 
> ###
> 
> Another issue is what happens if a device "grows" incompatible endpoints
> after being attached, ie a webcam could have no isoc endpoints in alt
> setting 0, and then grow an isoc endpoint on a set_interface. So we
> would need a check for a device becoming not fullspeed compat while
> being attached at fullspeed in usbredir_ep_info(), and then call
> usbredir_reject_device() when this happens.

...and this patch started so simple. OK.

> 
> Although not pretty I'm ok with this, since I actually want to add
> similar code to allow usb-3 (superspeed) devices like a usb-3 usb-stick
> to work with ehci or uhci controllers :)

Great, that would have been my next question, but I don't have hardware
for that around yet.

BTW, I'm facing several incompatibilities with passed-through CDC/ACM
devices (e.g. a Galaxy S2), independent of my patch. Both host-linux and
redir doesn't allow to use them properly but show different symptoms.
Need to analyze and report once time permits.

Jan



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

  reply	other threads:[~2012-09-17  9:19 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-15 16:27 [Qemu-devel] [PATCH] usb-redir: Allow to attach USB 2.0 devices to 1.1 host controller Jan Kiszka
2012-09-17  9:08 ` Hans de Goede
2012-09-17  9:18   ` Jan Kiszka [this message]
2012-09-17 14:24     ` Hans de Goede
2012-09-17 16:22       ` Jan Kiszka
2012-09-18  9:41         ` Hans de Goede
2012-09-21 11:49           ` Jan Kiszka
2012-09-21 12:21             ` Hans de Goede
2012-09-21 12:25               ` Jan Kiszka
2012-09-18 21:18       ` Anthony Liguori
2012-09-19  9:20         ` Hans de Goede
2012-09-22  9:29   ` [Qemu-devel] [PATCH v2] " Jan Kiszka
2012-10-08 17:36     ` Jan Kiszka
2012-10-08 23:05     ` [Qemu-devel] [v2] " Hans de Goede
2012-10-09  8:38       ` Hans de Goede
2012-10-09  8:40         ` Gerd Hoffmann
2012-10-09 10:05         ` Hans de Goede

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5056EAF2.60205@web.de \
    --to=jan.kiszka@web.de \
    --cc=hdegoede@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.