From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51155) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VTvmc-000623-LK for qemu-devel@nongnu.org; Wed, 09 Oct 2013 11:34:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VTvmW-0003V8-Mr for qemu-devel@nongnu.org; Wed, 09 Oct 2013 11:34:42 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34368) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VTvmW-0003Uy-EJ for qemu-devel@nongnu.org; Wed, 09 Oct 2013 11:34:36 -0400 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r99FYZ4a009857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 9 Oct 2013 11:34:35 -0400 Message-ID: <52557788.9030600@redhat.com> Date: Wed, 09 Oct 2013 17:34:32 +0200 From: Hans de Goede MIME-Version: 1.0 References: <1381262298-3241-1-git-send-email-hdegoede@redhat.com> <1381262298-3241-4-git-send-email-hdegoede@redhat.com> <1381308939.12583.27.camel@nilsson.home.kraxel.org> <52555548.2050106@redhat.com> <1381325723.12583.108.camel@nilsson.home.kraxel.org> In-Reply-To: <1381325723.12583.108.camel@nilsson.home.kraxel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 03/13] usb-host-libusb: Detach kernel drivers earlier List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: qemu-devel@nongnu.org Hi, On 10/09/2013 03:35 PM, Gerd Hoffmann wrote: > Hi, > >>> Assuming we have a device with multiple configurations, each >>> configuration has a different set of interfaces, guest switches from one >>> config to another. Do we correctly unbind kernel / claim interfaces >>> then? >> >> Yes we still have a usb_host_detach_kernel() call in the beginning >> of usb_host_claim_interfaces(), which gets run on the new interfaces >> immediately after the libusb_set_configuration call. > > Ok, good. > >> Doing a detach_kernel after a set_config has always been necessary, >> since the kernel will automatically bind drivers to the new interfaces >> if the set_config succeeds. > > Is there some way to avoid the kernel's autobind in the first place btw? Not atm, but so far the kernel guys have been open to adding (sane) API's for things like this, and avoiding the whole re-bind after a set_config from userspace would probably be nice to have. Note that this is not triggering in 99% of all cases though, as the kernel has this bit of code in its set_config handling for usbfs: /* SET_CONFIGURATION is often abused as a "cheap" driver reset, * so avoid usb_set_configuration()'s kick to sysfs */ if (actconfig && actconfig->desc.bConfigurationValue == u) status = usb_reset_configuration(ps->dev); else status = usb_set_configuration(ps->dev, u); So it only actually does a set_config (and binds the kernel drivers to the interfaces) if the guest is asking for another config then the host os has chosen for the device. Since the guest assumes the device starts unconfigured, it does not issue a set_config(0), only a set_config(1) (usually) which the above code turns into a light weight reset. Note that my usbredirhost code avoids even the unclaim / claim dance around set_config and calling into the kernel at all in this case, it has: if (host->config && host->config->bConfigurationValue == config) { goto exit; } A downside of this is that not even the lightweight device reset is done, but the guest always starts with a full device-reset, immediately following that with a lightweight reset has little value. I think we could and should to the same in host-libusb.c. Regards, Hans