From owner-freebsd-usb@FreeBSD.ORG Thu Oct 10 07:49:50 2013 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id EE836AFE for ; Thu, 10 Oct 2013 07:49:50 +0000 (UTC) (envelope-from hps@bitfrost.no) Received: from mta.bitpro.no (mta.bitpro.no [92.42.64.202]) by mx1.freebsd.org (Postfix) with ESMTP id 827F1271E for ; Thu, 10 Oct 2013 07:49:50 +0000 (UTC) Received: from mail.lockless.no (mail.lockless.no [46.29.221.38]) by mta.bitpro.no (Postfix) with ESMTP id BD8347A1D2; Thu, 10 Oct 2013 09:49:49 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.lockless.no (Postfix) with ESMTP id 2BBFD8F5E11; Thu, 10 Oct 2013 09:50:13 +0200 (CEST) X-Virus-Scanned: by amavisd-new-2.6.4 (20090625) (Debian) at lockless.no Received: from mail.lockless.no ([127.0.0.1]) by localhost (mail.lockless.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ctEf14N7ttu0; Thu, 10 Oct 2013 09:50:12 +0200 (CEST) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) by mail.lockless.no (Postfix) with ESMTPSA id 50D2F8F5E0B; Thu, 10 Oct 2013 09:50:12 +0200 (CEST) Message-ID: <52565C69.905@bitfrost.no> Date: Thu, 10 Oct 2013 09:51:05 +0200 From: Hans Petter Selasky Organization: Bitfrost A/S User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130522 Thunderbird/17.0.6 MIME-Version: 1.0 To: "aseem.jolly" Subject: Re: USB device configuration References: <1381274499940-5850403.post@n5.nabble.com> <5254FD72.2050507@bitfrost.no> <1381342263797-5850596.post@n5.nabble.com> <525649BB.2060906@bitfrost.no> <1381390376377-5850751.post@n5.nabble.com> In-Reply-To: <1381390376377-5850751.post@n5.nabble.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-usb@freebsd.org X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 07:49:51 -0000 Hi, On 10/10/13 09:32, aseem.jolly wrote: >> It is allowed to set the configuration multiple times. Refer to USB >> 2.0 specification. > > In what possible scenario would we want to set the configuration again? I > know USB 2.0 specification allows it. I have also tried to modify the code > and have sent SET_CONFIGURATION request to the device multiple times, and > device didn't report any error. Some devices have multiple configurations with different interfaces, which the application selects depending on the use-case. Many devices only have one configuration. > > Or do you mean different configurations of a device, if a device supports > more that one configuration? > >> Is this making a difference for you? > I have scene a case in which we were unable to attach the umass driver to > the device but since USB_DEBUG was not enabled at that time so I was not > able to get more information out of it and being extremely intermittent in > nature, I am not able to reproduce it again. I am trying to figure out the > possible scenarios in which we might end up not attaching the driver to the > device. I believe if we are not able to select a configuration then we don't > attach the driver to the device. > > In usb_unconfigure func: > > udev->curr_config_no = USB_UNCONFIG_NO; > udev->curr_config_index = USB_UNCONFIG_INDEX > > In usb_probe_and_attach func: > if (udev->curr_config_index == USB_UNCONFIG_INDEX) { > /* do nothing - no configuration has been set */ > goto done; > } > >>From the console logs, it is clear that SET_ADDRESS went successfully, have > noticed that we have assigned a ugen name to the device and also request to > get the String descriptors(Product, Manufacturer etc) went successfully so > that make me believe that there might be an error in performing > SET_CONFIGURATION request. Do you have any other suggestions? You can use "usbdump" to figure out exactly what went wrong with regard to USB requests. That might get you a clearer picture of what's going on. --HPS